Right now the panel code makes the left corner sync up with the
activities button and the right corner sync up with the user menu.
This is fine as long as we have an activities button and a user menu.
The login screen won't have those things, though.
This commit changes the panel corner code to try to figure out which
interface element is the most appropriate to sync up with based on
its position in the panel.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Images are part of the notification spec, so we should support them.
Marina Zhurakhinskaya provided some code for getting the layout right
for this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=621009
Have LayoutManager automatically deal with sizing and positioning
boxes for the panel and messageTray relative to the monitors.
Also, now that LayoutManager knows exactly where and how tall the
panel and tray are, have it manage the pointer barriers as well.
https://bugzilla.gnome.org/show_bug.cgi?id=612662
In order for transformation animations to look good, they need to be
incremental and have some order to them (e.g., fade out hidden items,
then shrink to close the void left over).
Chaining animations in this way can be error prone and wordy using just
Tweener callbacks.
This commit adds a new set of classes to help:
- Task. encapsulates schedulable work to be run in a specific scope.
- ConsecutiveBatch. runs a series of tasks in order and completes
when the last in the series finishes.
- ConcurrentBatch. runs a set of tasks at the same time and completes
when the last to finish completes.
- Hold. prevents a batch from completing the pending task until
the hold is released.
The tasks associated with a batch are specified in a list at batch
construction time as either task objects or plain functions.
Batches are task objects, themselves, so they can be nested.
For now, these APIs are temporarily getting staged in a gdm/ specific
subdirectory so they will be available for use by GDM. They aren't
specific to GDM, or even to doing animations, though, so the API may eventually
move in some form or another to a more general location. Alternatively, the
APIs may ultimately get dropped entirely and replaced by something else.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
A modal dialog in the shell blocks anything but that dialog from
receiving user input. Applications within the session and other
parts of UI are rendered non-reactive.
When GDM gets changed to use the shell for its greeter, the user
list will be presented as a shell dialog. That dialog shouldn't
block access to the panel menus, etc.
This commit adds a shellReactive property that makes the ModalDialog
class continue to block access to applications, but allow the user
to interact with the shell itself.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The control-center contains user-pertinent settings
panels. These panels don't make sense to show outside
of a user's session, so hide them for session types other
than SessionType.USER.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
We're not going to want an overview at the login screen,
but a lot of code in the shell depends on the overview
existing.
This commit adds a new isDummy constructor property to
allow creating the overview as a non-functional, stub object
that doesn't do anything visible.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The dash object is currently exposed as a public object.
It's only used outside of the overview for the dash object's
iconSize property though.
This commit makes the dash object private and proxies the dash
iconSize property to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Right now, when a user clicks on the panel clock, a menu pops up with a
calendar and a list of events from the user's schedule. The list of
events only makes sense from within a user's session, however.
As part of the prep work for making the shell a platform for the login
screen, this commit makes the events list optional.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The theme currently hard codes the minimum size of the calendar
menu to make sure there's a designated area for events
(even if there isn't anything currently scheduled).
A side-effect of the hard coded minimum width is that
if the events area is hidden, the menu ends up much
bigger than the calendar. We don't currently ever hide
the events area, but we will in the future.
This commit moves the min-width restriction from the menu
specifically to the events area.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
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
Right now, if buttons get set on a dialog after it is mapped,
they just pop in instantly.
We shouldn't have any harsh transitions like that, though.
This commit changes the buttons to quickly fade in, instead.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
All the system status menus in the panel offer a
menu item to jump to a relevant part of the
control-center.
This means each status icon has the same, or nearly the
same bit of code to:
- Add a new "action" menu item and listen for its activation.
- Hide the overview if it's showing when the menu item is activated
- Find the relevant control-center panel from its desktop file
- Launch the control-center to the relevant panel
This commit consolidates all those details in a new method,
addSettingsAction. This refactoring reduces code duplication and
slight inconsistencies in the code resulting from that duplication.
It will also make it easier in subsequent commits to hide settings menu
items when the shell is used in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
A separator only makes sense if there are items on both
sides of it. There is quite a lot of code written
throughout the shell that manages the process of showing
and hiding separators as the items around those separators
change.
This commit drops all that code in favor of changes to the menu
implementation to dynamically hide or show separators as
appropriate, so the callers don't have to deal with it.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Wireless and 3g dialog code has moved to gnome-control-center, so
we can stop calling out to nm-applet. Also, we can now enable the
notifications provided by the shell and kill a bit of code about
auth that is not actually needed.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
Using the new ShellNetworkAgent, show a system modal dialog
(similar to the PolicyKit one) when NetworkManager needs secrets
for connecting to wireless.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
The order of indicators depends on the order of calls to
Panel.addToStatusArea. To have it consistent across enabling and
disabling of extensions, we need to place the core ones first.
https://bugzilla.gnome.org/show_bug.cgi?id=653205
This way all standard indicators have a shell implementation
provided, which prevents issues with extensions enabling/disabling
(in particular with xrandr-indicator)
https://bugzilla.gnome.org/show_bug.cgi?id=653205
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 "id" variable was being sporadically reset to null, and as far as
Florian and I could determine, this is actually a Spidermonkey bug.
The issue has something to do with:
1) use of "let" for the variable
2) Nesting a dynamic closure inside of a for() loop
Work around it here for now - I tried to create a minimized test case
to hand to the Spidermonkey developers, but failed. A big part of
the problem is it's only sporadically reproducible.
Direction containers group all contiguous messages in the same direction into
their own parent container, allowing for smarter styling of similar messages.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
This adds a new DBus method: InstallExtensionRemote(uuid : s, url : s)
Pass it the UUID of an extension and the URL of a manifest file: the same as a
metadata.json, but with a special key, '__installer', which is an HTTP location
that points to an zip file containing the extension. The Shell will download
and use it to install the extension. In the future, the manifest file may be
used to automatically detect and install updates.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
The two similar keys were hard to manipulate to have specific effects, so just
remove one. Now there is an *explicit* whitelist: all extensions must be in the
'enabled-extensions' for them to be loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
It's generally more useful to see when a person sent a message instead of when
we received it. Also, a recent change in Telepathy made the received timestamp
be 0 for messages we send.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
Adds methods to shell_global to allow taking screenshots
save the result into a specified png image.
It exposes three methods via shellDBus applications like
gnome-screenshot:
*) Screenshot (screenshots the whole screen)
*) ScreenshotWindow (screenshots the focused window)
*) ScreenshotArea (screenshots a specific area)
https://bugzilla.gnome.org/show_bug.cgi?id=652952
It is not possible to connect to hidden access points without
knowing the SSID, and it should be done using the control center
panel and the appropriate dialog. At the same time, this should
fix some warnings from libnm-glib and dbus-glib.
https://bugzilla.gnome.org/show_bug.cgi?id=646454
The shell should only notify in case no other client handles the message.
Empathy will ack the message if focused, so we don't want to step on its
toes.
Use the existing setting
org.gnome.desktop.default-applications.office.calendar.exec
as calendar application instead of the hard-coded evolution. Evolution
is still the fallback if that setting is cleared (it defaults to
evolution).
https://bugzilla.gnome.org/show_bug.cgi?id=651190
