Pop up a dialog when trying to install an extension so that users are aware
they are installing one. This is a security precaution in the case that an XSS
exploit has been found on the website, which could cause someone to inject a
<script> tag and silently install an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
libsoup won't check for a valid cert by default, so copy some logic from
glib-networking to check against the system cert list. Additionally, allow a
fallback for developers, ~/.local/share/extensions.gnome.org.crt, for easy
local development of the website.
https://bugzilla.gnome.org/show_bug.cgi?id=658870
For those who like their system pure, this provides the ability to purge a
pesky extension and its precious place on your disk space, and in your
"Local Extension" list.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
Conflicts:
js/ui/extensionSystem.js
This ensures that we don't show an animation of an empty blob being hidden when
clicking an action button causes the notification to be destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=658525
The session list is supposed to hide itself if
1) the user is already logged in
2) there is only one xsession file installed
There was a bug causing 2) not to work.
This commit fixes that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=658423
findUrl() was seeing strings like "You have 1 new message in
foo@example.com/Inbox" and finding the URL
"[http://]example.com/Inbox". Require that URLs either start at the
start of the string, or are preceded by whitespace or an open
paren/quote/etc.
(Since JS doesn't have look-behind assertions like perl does, we have
to actually match the URL-preceding character in the regex, and then
adjust the result findUrl returns accordingly.)
https://bugzilla.gnome.org/show_bug.cgi?id=636252
Although "x:5" could theoretically be a URL with scheme "x" and path
"5", it probably isn't. Only URLify strings that use the "authority"
syntax ("foo://"). (No one ever types out "mailto:" URLs in ordinary
text, so we don't want to match those either.)
https://bugzilla.gnome.org/show_bug.cgi?id=636252
Explode the regex onto multiple lines, and add comments explaining the
pieces. Also, change ()s to (?:)s (non-capturing groups) where
appropriate, and replace the UTF-8 characters with \u escapes so that
they actually work.
https://bugzilla.gnome.org/show_bug.cgi?id=636252
When the keyboard is configured, make lg shorter (if necessary) to
avoid overlapping it.
Also, make a few simplifications to lg's layout code. In particular,
move it into panelBox, to simplify its interactions with the panel.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The keyboard and tray need to animate together, but they sometimes
need to be in different stacking layers (eg, from the screensaver you
want access to the keyboard, but not the tray). So remove _bottomBox
and just keep trayBox and keyboardBox lined up manually.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Rather than having a single chrome layer and putting all of the chrome
into that, put the chrome actors directly into uiGroup, so that they
can be stacked independently of one another relative to other actors.
(This requires making uiGroup a ShellGenericContainer, so we can use
skip_paint to avoid painting non-visibleInFullscreen chrome when we're
in fullscreen.)
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The struts were being set while the panel was offscreen (starting its
slide-in animation), and then belatedly getting fixed the next time
something else caused a chrome update. Fix this by setting them before
the animation, and freezing them during the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Force an allocation at thumbnails creation so we can figure out whether we
need to scroll when selecting.
We also need to show() the whole AltTabPopup before calling _select() so that,
when computing the scrolling offset, the widgets already have their styles
loaded. Otherwise we will miss the switcher list item container's spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=655069
At least for the foreseeable future, the gnome-session desktop
presence won't be used for anything but suppressing (non-urgent)
notifications. To clarify this behavior, rename the "Do Not Disturb"
switch to "Notifications" (and adjust the switch logic accordingly).
https://bugzilla.gnome.org/show_bug.cgi?id=652718
This patch fixes the "apps vanish from alt-TAB bug".
If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...). In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.
In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.
What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance. This ensures we preserve any state such as the
set of open windows.
This requires moving the running state into ShellAppSystem. Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.
This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation. As long as
we're on top of random broken tar+wget wrappers, it will be gross.
A slight future improvement to this patch would add an explicit
"merge" between the old and new data. I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=657990
As extensions are now expected to provide a "disable" function,
they need to remove search providers they added. Implement the
removal functionality and add a public removeSearchProvider()
method.
https://bugzilla.gnome.org/show_bug.cgi?id=657548
We keep track of presence changes by connecting to the
Tp.AccountManager:most-available-presence-changed signal.
However, if multiple accounts are in use, telepathy may
lie to us and emit the signal even when the most available
presence is unchanged.
Work around this by keeping track of the current presence
ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=657703
Some search providers may want to change their results, or may not
want to block on an external service to get their results (DBus, etc.)
Set up an infrastructure to allow search providers to add their search
results at a later time.
Based on a patch by Jasper St. Pierre and Seif Lotfy.
https://bugzilla.gnome.org/show_bug.cgi?id=655220
This adds contacts search to shell, powered by libfolks.
Changes:
- Add Folks and Gee to the build system
- ShellContactSystem, a backend in C
- ContactDisplay, search frontend in JS
https://bugzilla.gnome.org/show_bug.cgi?id=643018
The current user status menu allow to set the session status,
which also influences the IM status when signed in with
mission-control. However, the way it is presented to the user
makes it hard to figure out how the statuses interact or that
there are two distinct status in the first place.
Therefore, use a separate control for each status, and update the
overall look to match gnome-contacts.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Given that our menus contain at most two columns, all switch widgets
in menus end up in the last columns, and thus aligned with the right
menu edge.
However, the updated user status menu will contain a section which
ignores the menu's column layout, so the switch might end up in
the middle of the menu if the overall width is determined by said
section.
At least for now, we always want the switch to align with the end,
so just expand switch menu items rather than adding an option.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Introduce a new menu widget, which displays the active item from
a set of options, and pops up a child menu to allow changing the
active item when activated.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Allow opening a popup menu from another menu. While the child menu
is open, events on the parent menu are blocked. The parent menu
is kept open when the child menu is closed; the child menu on the
other hand is closed with the parent, e.g. when the focus moves
to another toplevel menu.
This feature will be used to implement combo box menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
We haven't actually been calling the top-right menu "status menu" for
quite some time, so use the upcoming code changes as an excuse for
renaming it to "user menu".
Doing this rather than overdrawing a black rectangle saves us
(pixels in screen) * 8 bytes of memory bandwidth for every frame we draw going
into the overview.
It also allows us to dim the background on non-primary monitors making the
overall overview appearance consistent across all monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=656433
Instances of this class share a single CoglTexture behind the scenes which
allows us to show the background with different rendering options without
duplicating the texture data.
https://bugzilla.gnome.org/show_bug.cgi?id=656433
This commit adds GDM session support.
It provides a user list that talks to GDM,
handles authentication via PAM, etc.
It doesn't currently support fingerprint readers
and smartcards.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The shell has a number of things that are only relevant for
logged in users (e.g. calendar events, telepathy integration, a
user menu, etc).
This commit moves those user session specific bits into their
own functions in preparation for making the shell code ready
for use at login time.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
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
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Add a helper function (mostly copied from gtkcalendar.c) for getting
the first week day for the current locale, using nl_langinfo if
available and falling back to the GTK+ gettext fallback otherwise.
Use that function in the calendar, so that the LC_TIME setting is
used if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=649078
Instead, create three ripples and keep tweening them. This gives a dramatic
speedup when entering the overview, but means that we can't have the same animation
running twice. In this case, we "reset" the currently running ripple animation, but
it is hard to notice unless looking for it.
https://bugzilla.gnome.org/show_bug.cgi?id=656125
Extension developers may be confused about why their extensions aren't working:
the LookingGlass isn't a very obvious place, or even which errors are theirs.
To remedy this, save all errors per-UUID which allows them to be retrieved
later.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
Add ShellVersion, designed for detecting OUT_OF_DATE extensions so they can't
be installed, as well as ApiVersion, designed for backwards-compatibility with
the SweetTooth web-app, which must support all shell versions.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
GetExtensionInfo() takes a UUID and returns a JSON object with information
about that extension including their metadata, path and current state.
ListExtensions() takes no arguments and returns a JSON object mapping UUIDs
to the same information objects described above.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
As an effort to prevent a string freeze to land timestamps on 3.0, we reused
translations for the calendar. Now that the string freeze is long gone, make
some proper strings.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
The notification spec supports the concept of a 'default' action:
"The default action (usually invoked my clicking the notification)
should have a key named "default". The name can be anything, though
implementations are free not to display it."
Support this by invoking the 'default' action rather than a emitting
the 'clicked' signal when clicking notifications which specifie a
default action.
Also don't add an action button for the default action.
https://bugzilla.gnome.org/show_bug.cgi?id=655818
LayoutManager and Chrome are already somewhat intertwined and will be
becoming more so. As a first step in merging them, move the Chrome
object into layout.js (with no other code changes).
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Looking Glass is supposed to slide out from underneath the panel.
Rather than fiddling with Main.chrome.actor directly, just add the lg
actor to the chrome, and fix its stacking there.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
With the old pre-boxpointer summary notifications, it sort of made
sense that the summary notification actor was a child of the message
tray. But there's no reason for that now, and in fact, it ends up
requiring special cases in some places since hovering over the summary
notification counts as hovering over the tray. So, fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Rather than having the panel corners as independent bits of chrome and
manually syncing their positions, put them inside the panel actor, and
update the panel's allocation code to position them correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
The buttons should have a glassy transparent look. Also, they should not
be as tall, should light up on hover, and their labels should be white
in order to stand out. Making the labels solid white requires removing the
transparency set in modalDialog.js. Also, add a separate color setting
for the dialog as a whole - this avoids having a white icon.
https://bugzilla.gnome.org/show_bug.cgi?id=655428
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
Since this link in the keyboard menu points to Region and Language
Settings in System Settings, we should be consistent and use that
term instead of "Localization Settings"
Also, this removes ellipsis from "Show Keyboard Layout" since it
doesn't require further input.
https://bugzilla.gnome.org/show_bug.cgi?id=652984
The current check for fullscreen windows ignores the window's
minimization state, so that chrome which is hidden in fullscreen
will always hide if the window on top of the window stack is
fullscreen, even if it is actually minimized.
Instead, skip minimized windows when looking for fullscreen windows.
https://bugzilla.gnome.org/show_bug.cgi?id=655446
_fixMarkup() was supposed to be ensuring that the markup we passed to
clutter was correct, but it was validating the syntax incorrectly, and
wasn't checking that the markup was valid (or even well-formed). This
is bad because if you pass bad pango markup to
clutter_text_set_markup(), it will g_warn and drop the string on the
floor.
Fix by fixing up the regexps, and then calling Pango.parse_markup() on
the result, and just xml-escaping everything if parse_markup() fails.
https://bugzilla.gnome.org/show_bug.cgi?id=650298
Keeping the volume menu open after setting the desired volume isn't that
useful and forces a second click (or an Esc press) to dismiss it. Allow for
the sliders to be used with a single click-hold-move-release.
https://bugzilla.gnome.org/show_bug.cgi?id=649586
Move the HotCorner class from panel to layout, and make the panel
manage its own HotCorner.
Stick the panel's HotCorner into the Activities button actor (rather
than separately floating above it), so that hover tracking on the
button works properly without needing hacks in HotCorner.
https://bugzilla.gnome.org/show_bug.cgi?id=645759
The fact that everything in the top bar except the activities button
was a menu made various things difficult. Simplify this by making the
activities button be a menu too, but just hack it up a bit so that the
menu associated with the button never actually appears.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=645759 (Clicking on
Activities with menu up leaves a funny state) and its semi-dup 641253
(panel keynav between Activities and menus is quirky).
visibleInOverview chrome was visible even when the screensaver was
active. Although we may eventually need visibleInScreenSaver, that
should be a separate flag.
Fix this by tracking the screensaver active state, and hiding the chrome
when the screensaver is active.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
Fix the signal handling; you can't use this.connect('ActiveChanged')
to connect to a D-Bus signal after replacing the signal methods with
the lang.signals versions. Just leave it using the D-Bus signal names,
just like it uses the D-Bus method names.
Also, remove the "_" from "_screenSaverActive", to match what
AutomountManager checks for, and remove getActive(), since it's not
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
As _updateCount has been designed to be overwritable by subclasses,
move the check for _actorDestroyed into _setCount(), to fix the
problem described in commit 5f6ac33d5 in derived types as well.
If the resident source is destroyed, it should be recreated
immediately, so that it is available when another volume is
mounted. However, we only connect to the 'destroy' signal
on the original source, not on newly created ones. As a result,
the resident source only works twice, after that it shows up
without icon and an empty notification.
Fix by always connecting to the source's 'destroy' signal.
When trying to update the message count after a summary icon has
been destroyed, the label to display the count is no longer valid
and trying to set its text results in some Clutter warnings.
Basically do what NautilusPlacesSidebar does with the drive/volume/mount
eject/unmount/stop priorities.
We follow this pattern:
- always prefer Safely Remove if available (i.e. drive.stop())
- fallback to ejecting the mount/volume/drive if that's not possible
- finally, fallback to unmounting the mount if even eject is not
available
This also means we don't care about the distinction between
Stop/Eject/Unmount at this level. Disk Utility (or Nautilus) are
available for those who want that degree of control, but the common case
here should do the most useful action without presenting the choice.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Ideally, this would be an entirely-JS implementation, but we have a
couple of issues with gjs and gobject-introspection to work around, so
we need a ShellMountOperation class for the time being.
This first commit implements the show-processes dialog, with a system
modal style very similar to the EndSession dialog.
Implementations of ask-question and ask-password will follow shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
If possible, use the results from the sniffer process in order to have
less-generic alternatives to the file manager in the proposed autorun
choices.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Autorun preferences can be fine-tweaked at the content-type level from
the System Settings 'Removable Media' panel.
Use those settings to figure out the default action for newly-mounted
mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
The AutomountManager class is the low-level counterpart of the
previously introduced AutorunManager, and takes care of extracting the
list of valid mounts from a GVolume or a GDrive and mounting them,
provided a number of conditions and requirements are met.
AutomountManager also keeps track of the current session availability
(using the ConsoleKit and gnome-screensaver DBus interfaces) and
inhibits mounting if the current session is locked, or another session
is in use instead.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
AutorunManager is a class that takes care of displaying and managing
notifications and UI for storage devices.
When a mount appears and a number of conditions are satisified, a
transient notification will be displayed to immediately interact with
the device. AutorunTransientDispatcher is the object that takes care of
showing/hiding the notification sources as devices appear/disappear.
Likewise, current mounts are kept in a list and presented within a
list in a resident notification, handled by AutorunResidentSource.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
On error, we tried to kill and respawn gnome-power-manager, but
as of commit c5676900 the DBus interface provided by g-s-d's power
plugin is used, so the respawning does not have any effect.
https://bugzilla.gnome.org/show_bug.cgi?id=654300
When one of the networks in the main menu is removed and we have
a More... submenu, we can take the first out from the submenu and
show it in the main menu.
https://bugzilla.gnome.org/show_bug.cgi?id=647175
This is needed if we are handling an incoming text channel and then user tries
to open a chat with the same contact using Empathy. In this case, the Shell
should delegate the channel back to Empathy and just continue observing it as
it does for usual outgoing channels.
Depends on telepathy-glib 0.15.3 as
tp_base_client_set_delegated_channels_callback() has been added in this
version.
https://bugzilla.gnome.org/show_bug.cgi?id=654237
Due to an accidental addition line in commit c8670819, all switches in popup
menus accidentally gave the appearance that they were turned off.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
https://bugzilla.gnome.org/show_bug.cgi?id=654267
We don't want sources that are no longer associated with a running application
to stick around in the message tray.
Message tray sources were removed when the associated application’s state
changed to Shell.AppState.STOPPED . This caused sources for applications
that were still running, but did not have any open windows to be removed.
Instead, we should use the notification’s sender removal from DBus as an
indicator for when to remove the associated source from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=645764
If we're typing we want to send composing. If we empty the entry we
want to send active. If we're typing but don't type any more for
COMPOSING_STOP_TIMEOUT seconds, we want to send paused. Simple.
This behaviour was stolen from Empathy where it has won many awards.
https://bugzilla.gnome.org/show_bug.cgi?id=650196
Based on patch from Jonny Lamb <jonnylamb@gnome.org>
Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
Commit 64b2b4a7d4 changed the monitor layout handling, resulting
in some layout errors due to a subtle change in memory handling:
when zooming a window in the overview, the available zoom area is
calculated by subtracting the panel height from the primary monitor
area. This area used to be a copy of the monitor rect, but as now
the rect itself is returned, zooming a window on the primary monitor
repeatedly modifies the monitor rect, leading to layout errors in
various parts of the shell.
Fix by using a copy when calculating the available zoom area.
https://bugzilla.gnome.org/show_bug.cgi?id=654105
Use a longer fade-in time, but with an inout transition, so that the
dialog starts fading in very slowly and then picks up speed after
150ms or so. That way if the user releases Alt+Tab right away, they'll
never actually see the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=652346
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
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
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
Due to lockdown settings or Polkit policy, shutdown may not be
available. If this is the case, the "Power off ..." action should
be hidden from the user status menu.
https://bugzilla.gnome.org/show_bug.cgi?id=652038
Sliding out the workspaces pager when starting a drag causes a lot
of motion. With the pager only hiding if workspaces are not used,
it is better to require to explicitly hover the workspaces sidebar
for the sliding.
https://bugzilla.gnome.org/show_bug.cgi?id=652730
Use the new PopupSwitchMenuItem functionality when bluetooth cannot
be enabled. Use it also for showing "connecting..." when activating
device items.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
Moves and converts NMDeviceTitleMenuItem from network.js into
PopupSwitchMenuItem, so that it can show both a switch and a
greyed-out status label. This will be soon used by the Bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
_createNetworkItem was always appending access point at the end of
the menu when their position was < 5 (NUM_VISIBLE_NETWORKS), ignoring
the presence or absence of _overflowItem, which thus ended in the
middle of the network list. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=652313
After completing the overview transition, the workspace view is
clipped to avoid overlapping the search entry/view selector titles
while switching workspaces. For clipping, the view's position and
size was used, which works well assuming that the workspace pager
will start hidden or stay zoomed out while the overview is visible.
However, that assumption holds no longer true, as auto-hiding the
pager now depends on the number of workspaces, and thus may change
while in the overview. For instance, when starting with the pager
being visible, the clip area ends up being too small when moving
all windows to the first workspace (and thus triggering auto-hide).
As a fix, handle the clip rectangle separately from the view's
geometry, and set it always to the area the workspaces would
occupy with the pager hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=653142
We call global.sync_pointer() on MetaScreen::restack as a hack to try
to fix up the hover state after a pointer grab. Previously we were
doing this in chrome.js, since there was already a ::restack handler
there anyway, but this isn't really related to the chrome at all, so
move it to main.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
Workspace thumbnails are supposed to be miniatures of the "real"
workspace they represent, but currently they show minimized windows
like the window picker.
Instead, hide minimized windows and track changes to update the
thumbnail accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=651569
With commit 59a3e393f9 whether the workspace pager should autohide
now depends on the number of workspaces. As we only track changes
to the number of workspaces while the overview is visible, we miss
changes in "normal mode", i.e. when creating a new workspace by
moving a window with ctrl-alt-shift-arrow; as a result, the pager's
autohiding might be incorrect when entering the overview after that.
As a fix, keep tracking changes to the workspaces when the overview
is hidden and update the zoom options.
https://bugzilla.gnome.org/show_bug.cgi?id=653078
Commit 429f809b7 fixed an exception in getDragActorSource(), but
the returned actor is only an approximation (e.g. in contrast to
the actual drag actor, it includes the label).
Try a bit harder to return the correct actor and only fall back to
the approximation when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=645990
The purpose of autohiding the workspace pager on the right was to
avoid exposure of workspaces to users who are not using them.
However, for users who do use workspaces, the behavior limits the
purpose of the overview. To fix, always show the pager if more than
one workspace is actively used.
https://bugzilla.gnome.org/show_bug.cgi?id=652714
Using the list of stylesheets loaded with st_theme_load_stylesheet(),
one can build an StTheme that is completely identical to the previous
one, except for one property (application-stylesheet).
This allows rt and the user-theme extension to work while respecting
the theming of other extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=650971
Currently the user has to find an empty spot in the workspace
to be able to launcha new instance of an app using dnd.
This is unnecessary hard, so just allow dropping on windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=652079
The screen panel in System Settings has a preference whether the
screen should be locked on suspend. This works fine when suspending
by closing the lid, but the "Suspend" menu item in the user status
menu ignores the setting and always locks the screen.
Fix by activating the screen saver before suspending rather than
locking explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=652327
As the Shell does more than observing channels (users can interact with them),
it has to be an Handler as well. We have to make sure that all the new
incoming text channels are handled by the Shell by default, so we make it an
Approver as well.
From an user point of view, the only difference is that Empathy's tray icon
will stop blicking when receiving new channels.
We rely on ChannelDispatcher.DelegateChannels() and PresentChannel() to
interact with Empathy. Those methods have been implemented in
telepathy-mission-control 5.9.0 and telepathy-glib 0.15.0.
If we have more than 5 (which can happen with VPN connections), place
them into a More... submenu, which also becomes scrollable if needed.
To protect from race conditions and ordering issues while reading
connections, sort them in alphabetic order when the timestamp is equal.
https://bugzilla.gnome.org/show_bug.cgi?id=651602
shell_global_get_memory_info() is a new function which extracts a few
global counters we have already, namely glibc's mallinfo, spidermonkey's
JSGC_BYTES, and gjs' counters for boxed/object/etc wrappers.
There is some slight overlap with perf; ultimately though I'd
like this function to do some more extensive analysis, so it wouldn't
be quite the same.
perf is going to be mainly concerned with how big the whole process
over time is; memory_info is for debugging memory leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=650692
When timestamps or presence or alias changes were appended before,
the _history could grow unbounded, leaving behind an unfruitful chat
log of:
Jasper has gone offline.
Jasper has gone online.
Jasper has gone offline.
Jasper has gone online.
ad nausem.
https://bugzilla.gnome.org/show_bug.cgi?id=651086
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
Currently the workspace geometry is updated on zoom/allocation
changes, which means that newly added workspaces use their initial
geometry of (0, 0, 0, 0) until the next zoom change. As a result,
windows on the affected workspaces are mispositioned, e.g. placed
outside the workspace area. To fix, set the geometry on newly added
workspaces to the view's cached values.
https://bugzilla.gnome.org/show_bug.cgi?id=649001
Workspaces used to contain the desktop background, so when a
workspace was removed, we animated its actor to an off-screen
position before destroying it. As the background has been
removed a while ago, we can destroy the actor directly.
https://bugzilla.gnome.org/show_bug.cgi?id=645031
If the former is empty (default), only the extensions not contained in
the latter are loaded. Else, all extensions in the former that are
not contained in the latter are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=651088
We should only show the trash can when the user starts dragging a
favorite from the dash, not when the user starts dragging an application
that happens to be a favorite via a window or an application icon
in the applications view.
https://bugzilla.gnome.org/show_bug.cgi?id=642895
Some users are confused when their devices are not shown in the
network menu, even if they configured them manually. Mark their presence
by showing them in the menu, even if they cannot be otherwise
interacted with.
Also add a status string for deactivating devices (none currently,
soon will appear in NetworkManager).
https://bugzilla.gnome.org/show_bug.cgi?id=646946
A new envrionment variable GNOME_SHELL_ENABLE_CLEANUP is added which
causes us to attempt freeing global data. The reason this isn't
enabled by default is that it's a waste of time at best, and at
worst in corner cases could cause crashes which would fill up
crash databases. Better to leave it as a developer-only tool.
Start stubbing out some cleanup in ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=649517
Since both the hot corner's ClutterGroup and the hot corner's
ClutterRectangle button-release-event is connected to
_onCornerClicked() we must handle it there by returning 'true' to
Clutter or else _onCornerClicked() is called twice which defeats the
HOT_CORNER_ACTIVATION_TIMEOUT logic.
https://bugzilla.gnome.org/show_bug.cgi?id=649427
If you receive a message, a notification will appear. If you reply in
Empathy's chat window before the notification disappears, the
notification is updated with the contents of the message you *just*
sent! We should only update notifications if they're incoming.
https://bugzilla.gnome.org/show_bug.cgi?id=650219
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
AltTabPopup was calling global.stage.get_actor_at_pos() "to force a
stage relayout", but that function does not actually have that effect.
It was also occasionally causing Clutter warnings (possibly due to a
clutter pick-buffer-caching bug?). So just remove the call.
https://bugzilla.gnome.org/show_bug.cgi?id=650317
Move some more environment-initializationy stuff from main.js to
environment.js, and be more careful about not importing shell JS
modules until after the environment has been fully patched.
Change gnome-shell-plugin to call Environment.init() before
Main.start(); this means that Environment.init() now runs before any
shell JS modules (besides environment itself) have been imported.
Make run-js-test create a ShellGlobal and use its js_context, so that
the shell_global_set_property_mutable() stuff in Environment.init()
will work correctly in tests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=649203
The lg window was losing focus when the page with the entry got unmapped;
fix it to refocus itself after that.
Fixing this problem revealed that previously we were focusing the
entry on open(), but not ensuring that that page was selected, meaning
you could type into the entry without being able to see it. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=647303
The mouse-wheel zooming "easter egg" breaks horribly when you
drag a window, due to ugly lightbox reparenting tricks it uses.
For now, just end any zoom before we drag the window around.
https://bugzilla.gnome.org/show_bug.cgi?id=649632
All WPA APs were getting set as WPA2 due to the check for privacy;
WPA/WPA2 APs *must* set the Privacy bit according to the standard,
so we'd never end up in the case for NMAccessPointSecurity.WPA.
Fix that, and also add flags for WPA[2] Enterprise which we'll
use a bit later for the first-time connect case for 802.1x enabled
access points.
Instead of rolling our own code, use new libnm-glib functions to do
the same thing. Requires libnm-glib as of
779215c742bbe29a2c66202ec7e2e6d43edeb8ff (which will be part of 0.9).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=648648
A "cosmetic" code arrangement I requested in code review resulted
in one too few items being removed from the queue for each incremental
chunk of icons added. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=648739
We used used to indicate to the user the ability to move to another workspace
during dnd by highligthing the adjacent workspaces on hover.
This was done by changing the workspace's opacity to 200 and set it to
255 for the highlighted adjacent ones.
This is now no longer needed as the design was completely changed since
then (overview relayout; we no longer represent workspaces in the way
we did before) and introduces a bug where we don't properly reset the
opacity after the drag action, so just remove that code.
https://bugzilla.gnome.org/show_bug.cgi?id=648983
If the user typed "a", hit up, and pressed enter again, we wouldn't re-set the
history pointer to the end, so the broken navigation would instead go to the
entry before that.
https://bugzilla.gnome.org/show_bug.cgi?id=648765
If a user is fast and mouses over a window while the workspace thumbnail
animations are playing, it can be frustrating when the close button won't
appear at the end of the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=645848
The initial selection of the Alt+Tab dialog was happening before the
dialog was shown and allocated, and so the "do we need to scroll"
check used bogus coordinates. Fix by showing the dialog (and forcing
an allocation) first.
https://bugzilla.gnome.org/show_bug.cgi?id=647807
Previously, we skipped rebuilding device items in case the device
had already been seen, but this caused the connected switch not to
be updated. Now it has been refactored to update in case the device
changes, and to create only when the device is completely new.
https://bugzilla.gnome.org/show_bug.cgi?id=647565
Connect to button-press-event on the menu item actor, not on the
slider, so any part that is highlighted is also clicked. This means
that click on the left of the volume slider is a rapid way to mute.
https://bugzilla.gnome.org/show_bug.cgi?id=646660
Adds a function that compares wireless networks and keeps them sorted
at all times. Order is: first already configured connections, then
first secure networks, then alphabtic. Also, the appearance of a new access
point no longer causes the whole menu to be rebuilt (but it still linear
searches for the position, I guess that could be skipped), which caused
the addition of more code for tracking the active access point.
https://bugzilla.gnome.org/show_bug.cgi?id=646580
Rename a few Panel fields and add a _statusArea object pointing to the
status area PanelButton objects. You can now address each item
consistently from lg:
Main.panel._activities
Main.panel._appMenu
Main.panel._dateMenu
Main.panel._statusArea.a11y
Main.panel._statusArea.volume ...
Main.panel._userMenu
https://bugzilla.gnome.org/show_bug.cgi?id=646915
If a JS object has an 'actor' property pointing to a ClutterActor,
include the actor's toString() output in the delegate's toString()
output. Eg:
js>>> Main.panel
[object Object delegate for 0xff6080 StBoxLayout.menu-bar "panel" ("Activities")]
https://bugzilla.gnome.org/show_bug.cgi?id=646919
To keep the app icon from overlapping the panel's (border-image)
border, a custom property for clipping the app menu icon's bottom
was introduced. But if the clip region is set before the initial
icon is set, the entire actor ends up clipped. Also due to the double
meaning of clutter_actor_get_height() (e.g. preferred height versus
allocated height), the clip region may end up too large and the icon
overlaps the panel's border-image.
Fix both problems by updating the clip region on size changes as
well, rather than on style changes only.
https://bugzilla.gnome.org/show_bug.cgi?id=644122
The IP_CHECK and SECONDARIES states should be considered part of the
"connecting..." phase.
DEACTIVATING should be its own stage, but that would break string
freeze, so we just treat it like DISCONNECTED for now.
UNMANAGED needs to be treated differently in 3.2, but it is too late
to fix it for 3.0.1.
https://bugzilla.gnome.org/show_bug.cgi?id=646946
Alt+Tab's special case of "switch to the most-recently-used window even if
it's in the same app" is actually an hindrance for users to get a firm mental
model of Alt+Tab. Now that we have Alt+Above_Tab the special case is no longer
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=647907
Currently, the banner text is always located at the right of the
title - we need to swap those around for RTL locales. Rather than
using the locale directly to figure out the ordering, try to
determine the direction of the title label and let it control the
overall direction of the notification - this way, notifications
generally come out right when mixing scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=646921
In the current implementation of the search entry, when replacing a
selected search term with another term, the first character of the
replacement is prepended to the hint text rather than starting a new
search. This fix makes sure that the focus is not lost when changing
the selected search term.
https://bugzilla.gnome.org/show_bug.cgi?id=636341
When updating search results, the current result set is
recreated from scratch before setting the selection
highlight. This results in two style changes of the selected
item, and as a CSS transition is used to animate the style
change, the selected item flickers if it remains the same as
with the previous search term.
Fix by hiding the result set until the selection is set, to
avoid the transition in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=646019
The addition of _backgroundStack to ModalDialog broke focus
navigation, because it was interposed between the focus group root and
all of the interesting content, but since it isn't an StWidget,
st_widget_navigate_focus() was unable to navigate through it. Fix this
by moving the focus root to this._dialogLayout (inside the
_backgroundStack) instead.
Additionally, in EndSessionDialog specifically, _initialKeyFocus
wasn't being set until after opening the dialog, so it was ignored.
Also change ModalDialog.close() to clear the _savedKeyFocus that
popModal() set, so that dialogs that are repeatedly closed and
reopened will have their focus revert back to _initialKeyFocus each
time.
https://bugzilla.gnome.org/show_bug.cgi?id=646740
The icon set as secondary icon of the search entry depends on whether
a search is active or not - clicking the icon should reset the entry
only in the former case. This is implemented by connecting/disconnecting
the 'secondary-icon-clicked' signal when updating the icon, but an
additional signal connection was left-over when refactoring the search
entry, resulting in clicks on the inactive icon removing the hint text.
Fix by removing the stray signal connection.
https://bugzilla.gnome.org/show_bug.cgi?id=646855
The change to StTextureCache for bug 644142 broke lg's inspector icon,
which was not specifying St.IconType.FULLCOLOR, but was relying on the
fact that SYMBOLIC (the default) would fall back to it. Fix the icon
by specifying FULLCOLOR explicitly.
(We should probably be using a symbolic icon here, but there is no
available icon with a select/pick/point-to/etc kind of meaning.)
https://bugzilla.gnome.org/show_bug.cgi?id=646451
When more than one device exists, we need to reset the section title's
device to null, and in that case we must show nothing (neither the switch
nor the label, but an empty label is OK anyway). Also, we need to
update the device statusItem immediately when constructing it, as we
may not get any state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=646074
