Commit 08690d658f generalized the banner-blocking behavior of the
dateMenu to all menus that would obscure the banner. However setting
up the 'open-state-changed' handler only when an indicator is added
does not work for indicators that change their entire menu (like the
app menu) - we currently end up with menus with no connected signal
handler, and throw an error when trying to disconnect an invalid
signal ID.
To address this, add a new PanelButton::menu-set signal and use that
to set up the 'open-state-changed' handler.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
When opening a panel menu, we set it's max-height to the available
work-area height to keep menus with scrollable content from growing
outside the monitor. However a menu that extends all the way down
to the bottom edge does not look great either, so also take margins
into account here.
https://bugzilla.gnome.org/show_bug.cgi?id=744498
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
No sequence checks are done, these UI elements promptly trigger a grab that
will cancel ongoing touches and redirect later ones somewhere else, so that
works as a barrier to multi-toggling.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
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
A PanelMenuButton added to the top bar might not be visible at all
times. If it is hidden while the corresponding menu is open, we
currently don't do anything at all, e.g. the menu remains open
pointing to an arbitrary location in the top bar.
Instead, close the menu automatically in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=703540
Instead of faking it by adding a bunch of main icons and secondary
icons to our own box, try and recreate the original button box
with the original icons.
https://bugzilla.gnome.org/show_bug.cgi?id=690589
Panel already forces each item to be a PanelMenu.Button, so it's better
to have the latter handle the bin container too, instead of attaching
a private property that might collide with internal usage by the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
If we don't freeze the presence icon, we can end up in a place where
we'll be updating the icon before we fade out the panel indicators when
coming back from the lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
The design has a combined volume-network-power indicator in the lock
screen, which when opened shows a volume slider. Implement it by abstracting
the volume menu into a PopupMenuSection, and by creating three StIcons
bound to the real ones.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
Track locked status and use it to provide a reduced version of
the panel in the locked screen. Accessibility, input sources and
volume menus are preserved, without the link to the control center.
Network, battery and user menu are reduced to pure indicators,
with no menu.
This is similar to the design but not exactly, because designers
in IRC said that network needs more analysis before exposing, and
because the design didn't account for a11y and IM (so the one menu
metaphor is not really appropriate).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Previously, PanelMenuButton would only set max width if the user
explicitly clicked the menu button, resulting in submenus without scrollbars
if opened via keyboard navigation or mouse over.
https://bugzilla.gnome.org/show_bug.cgi?id=658946
Use the new GApplication support in ShellApp to create the application
menu. Supports plain (no state), boolean and double actions.
Includes a test application (as no other application uses GApplication
for actions)
https://bugzilla.gnome.org/show_bug.cgi?id=621203
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
Simplify the layout in rightBox by getting rid of statusBox, and just
putting everything into rightBox directly.
Simplify the handling of the user menu by adding it like it was a
status icon rather than special-casing it. Rename the "tray_icon"
variables to "status_area" to reflect this better.
https://bugzilla.gnome.org/show_bug.cgi?id=651299
The chrome layer contains the user interface elements (e.g.,
the panel) that disappear when fullscreen windows get displayed.
Panel menus are currently put in the chrome layer, but don't need
to be, since they are only displayed when the user is interacting
with the shell and not a fullscreen application.
Putting panel menus in the chrome layer does mean they will get
stacked below shell interface elements that aren't in the chrome layer,
though.
This commit changes panel menus to be on the same layer as most other
shell elements, so they get properly stacked above those elements.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Extensions often want to add items to the system status area, so it
is useful to add a convenience API for it. Also, we now allow
for cleaner destruction of panel objects, by just calling destroy()
on it.
Based on a patch by Jasper St. Pierre.
https://bugzilla.gnome.org/show_bug.cgi?id=653205
The specs call for a 2 pixel gap between the panel and its menus,
though we need to specify this as 4 pixels, since it's relative to the
bottom of the icon/title, not the bottom of the panel (up until now,
the point of the menu arrow was actually overlapping the menu's
highlight underline).
Also, move the gap specification into the CSS, since it makes more
sense there.
https://bugzilla.gnome.org/show_bug.cgi?id=655627
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
Every place that called chrome.addActor was specifying
visibleInOverview:true, and no existing designs call for chrome that
disappears when you enter the overview, so just drop that as an
option.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
Right now, the network menu will overflow the screen if More...
is selected with many access points. As a short-term workaround
for this, add a scrollbar for submenus of panel dropdown menus
if they would cause the toplevel menu to overflow the screen.
- Put the actors in a PopupSubMenu in a StScrollView so we get
a scrollbar if the allocated space is smaller than the height
of the menu. Expand animation is turned off in the scrolled case
to avoid weirdness.
- When we pop up a panel menu, set a max-height style property
on the panel menu to limit it to the height of the screen.
- Hack event handling while the scrollbar is dragged to make
the scrollbar work properly.
https://bugzilla.gnome.org/show_bug.cgi?id=646001
PopupMenuManager was pretending that it knew nothing about the menu's
sourceActors, while also trying to handle keynav between them. This
was a big mess, and resulted in bugs in navigation between panel menus
and the Activities button, and it totally gets in the way when trying
to add keynav to the dash (whose menu sources are arranged vertically
rather than horizontally).
Fix this up by moving the panel-specific parts to PanelMenuButton
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
Commit c86a977564 removed :pressed from the list of styles which
highlight panel buttons, so the button highlight is now lost when
mousing over menu items. This is not the behavior we want, the
buttons should keep their highlight while being "active". Rather
than adding back the pseudo class to the CSS, let buttons use the
:active pseudo class when the menu is open, which makes more sense
than :pressed anyway.
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
