There is currently no simple way to inject into AppIcon's state change,
so an extension that wants to do this has to destroy/remove/update all
icons in the Shell (i.e. in the Dash, AllView, FrequentView) on enable()
and disable() after updating AppIcon.prototype._onStateChange, or the
extension must require a restart of the Shell.
To solve this issue, we rename _onStateChanged to _updateRunningStyle,
and connect the notify::state signal with an anonymous function that
calls _updateRunningStyle.
This extra function call should allow extensions to just extend the
updateRunningStyle function in the prototype.
https://bugzilla.gnome.org/show_bug.cgi?id=739497
This patch inlines the function _ellipsizeEventTime into its only caller
_addEvent. This also removes the need for the global const
EventEllipses and is thus removed by this commit as well.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
With commit dc6a60dde, the calendar displays the ending day and time of
a continuing multi-day event on its ending day. This results in the list
not appearing to be sorted. This patch sorts the list according to the
displayed day/time.
With the two appointments
Thursday 0800-1000 Foo, and Wednesday 0900-Friday 1200 Bar and today
being Monday, the rest of the week list currently displays:
F ...1200 Bar
T 0800 Foo
With this patch, the displaying order is switched because Friday comes
after Thursday.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
Currently, multi-day events are shown as individual appointments on each
day. This patch ellipsizes multi-day events to indicate continuation on
the prior or following day (or other time-period.)
The time label spot is now replaced by a box layout that contains the
prefix ellipsis label, the time label and the postfix ellipsis label.
In order to keep the alignment, ellipses are merely invisible (zero
opacity) when hidden.
The ellipses are styled using the events-day-time-ellipses class which,
by default, take the color of the event text.
When RTL is used, the box contents are adjusted accordingly (clutter
does that for us).
An event spanning three days now displays "...All Day..." in the
calendar on the second day.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
It is really annoying for the user to acknowledge multiple notifications
when they queue up. So, to prevent a notification flood that has to be
handled by the user one-by-one, a summarized-notification feature is
added which leaves a single summarized-notification for the user,
replacing multiple notifications if the number exceeds 1, which they may
or may not acknowledge. When this summarized-notification is acknowledged,
the message-tray is opened where they can view the notifications that were
summarized. This helps the user concentrate on his primary task
simultaneously informing them about the new notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=702460
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
Since the background rework, SystemBackground is no longer a transparent
actor that you have to stack on top of a solid background, it is an
opaque actor. Fix the color of the background actor, and remove places
where we were setting the background color underneath the system background
and expecting blending - in particular, we can always set no_clear_hint
on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=738652
When monitors change, the previous index might not mean the same
physical monitor anymore, in fact, it might become invalid. In the
latter case, we'll actually get a JS error when accessing
this.keyboardMonitor in _updateKeyboardBox() . To avoid this, let's
just always reset the OSK to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=738536
Most of the code handles the sources setting being empty and
InputSourceManager.currentSource being null because previously the
"model" (i.e. the sources list) was kept in gnome-settings-daemon.
But this is fragile and since we're now the canonical place where the
list lives we can force it to never be empty even if the gsetting is
empty or contains only invalid entries. Adding the default keyboard
layout in that case is the safest thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=738303
Commit a4475465f1 fixed the wrong alignment for the fully visible
control, but regressed the partially slid-out one; take the slideX
factor into account to get the right offset for both cases.
Controls that slide left are located on the left, so the offset to
align them with the corresponding edge is always 0. It's controls
on the right that need a different offset when the available width
exceeds the child's width.
https://bugzilla.gnome.org/show_bug.cgi?id=728899
Currently we use the same amount of total delay divided by all items,
but that makes the items animate slow if the amount of items is small.
To avoid that, use a smaller total amount delay for an amount of items
smaller than four.
https://bugzilla.gnome.org/show_bug.cgi?id=737017
This commit ensures the login screen gets focused after
the screen shield is raised.
The code affects the unlock screen as well, but it's
less important since the unlock screen gets destroyed
and recreated each time the curtain moves, so it
has an opportunity to take focus on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=708105
We currently allow infinite number of screenshot requests to be active at
the same time, which can "dos" the system and cause OOM.
So fail subsequent requests for the same sender when a screenshot operation
is already running.
https://bugzilla.gnome.org/show_bug.cgi?id=737456
We currently just clear out the map of recorders (which results
in the top bar indicator to be hidden), but don't stop the actual
recordings.
Spotted by Adel Gadllah on IRC.
Instead of waking up the JS every second to set the clock and update a
date label the user will rarely see, simply use property binding to
bypass JS string handling, and update the date in the menu when the menu
is opened.
Checks for a duplicate search before setting the current search
to true and before cancelling the current search. This ensures that
if a duplicate search occurs while the previous search is still active,
the duplicate search will not incorrectly cancel or change the state
of the previous search.
Indicate to NetworkManager that the Shell's agent supports VPN
hints, and pass those hints to VPN auth dialogs that also indicate
that they support hints.
VPN plugins can request new secrets, for example if the previous
ones are incorrect (eg, user mis-typed the password) or some other
reason (next token code required to re-sync a hardware token).
The specific secret that the VPN wants, and a VPN-specific message,
are passed in hints from the plugin, to NetworkManager, to the
agent (GNOME Shell) and then to the auth dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=737592
If we have a modal, the stage's input region doesn't really matter --
all events go to us anyway. To avoid doing extra work doing animations
when we have a modal, like menus, the overview, and the message tray,
just fizzle out all updates.
To make sure we catch updates, update the input region whenever we end a
modal.
https://bugzilla.gnome.org/show_bug.cgi?id=737001
When the overview is created, search is populated with one actor for
each provider. As they're not hidden though, they will contribute to the
overall size request of the search page, which will shift upwards the
overview grid.
Reviewed-By: Jasper St. Pierre <jstpierre@mecheye.net>
Since (mutter) commit 49400657caae27 we disable the "Always on Top"
action for maximized windows, however when commit e7af257814
moved the window menu into the shell, this behavior was accidentally
extended to partially maximized (including tiled) windows.
As it can be desirable in this case to keep the window visible while
interacting with a different one, restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737382
MetaBackgroundCache doesn't itself use file watches, so when a image
that we are monitoring changes we need to purge it from the cache,
so that when we load it again we get the new image.
https://bugzilla.gnome.org/show_bug.cgi?id=710756
When the keyboard is destroyed, we destroy the keyboard actor, but the
keyboard's menu isn't part of the key itself, so it's never tracked.
The menus are actually tracked actors, so they slow down the layout
manager's code to rebuild regions and other things. Keeping this list
small is a good idea.
To prevent leaking menus, destroy the menu when the key is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=736999
The spring animation has to use clones to escape any clip set on the
parent, as it mainly occurs outside the parent. The same does not apply
to the pulse animation, which is very much in place - in fact, if the
parent is clipped (for instance a scrolled app folder), not having the
clip applied to the animated icons is indeed wrong.
Just animate the original grid actors instead, which gives the expected
result.
https://bugzilla.gnome.org/show_bug.cgi?id=736885
Trying to open an empty folder currently leaves the parent view in a
rather confused state. While we should look into fixing this in the
future, empty folders are not useful at all to begin with, so hide them.
https://bugzilla.gnome.org/show_bug.cgi?id=736910
The summary container will trap the focus if any sources are present,
making the message tray menu unreachable by keynav. Apply the same
hack as in searchDisplay and add a focusTrap to move the focus manually
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=707799
Can't wait to double the size of this list when these start using D-Bus
activation.
These were actually renamed in GNOME 3.12, but we couldn't do anything
about it before, and now we can.
It was assumed that BackgroundSource objects were always destroyed
on monitor changes because the BackgroundManager objects that hold
references were destroyed, but sequencing of updating of different
BackgroundManager objects meant that was not the case.
Properly update any cached Background objects held by the
BackgroundSource on a change to the monitor layout; in particular this
means updating animations in case they are multi-resolution.
All other submenus link to the corresponding settings, so we should
do the same for location - the privacy panel in this case, which now
sports a "Location Services" switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=736542
This lets us considerably clean up the event flow here and change how
things are structured. It also makes sure that we never show "No
Results" -- search.js not being aware of the timeout means that it might
not think that any work was being done when we show the page.
Keep a flag depending on whether a provider is in-flight, and use that
to determine what status label to show.
This ensures that we only show "No Results" when we're done searching
and we're sure that all providers have returned results back to us.
The complexities of tracking these two things separately, with the
display on one half, and the searching on the other half, is difficult
to manage. Squash it all together.
It is quite weird to have those calls/signals using WindowClone as an
argument, it is neater to pass MetaWindows around, and have each user
deal with their own representations of these.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
And use it to lookup the local WindowClone that applies. Otherwise,
WorkspaceThumbnail.WindowClone objects may be mistakenly set, which
are not usable interchangeably with Workspace.WindowClone ones. This
may lead to several misbehaviors as fields available in the second
object but not in the first one are accessed, some those undefined
values get used in math ops, which result in NaNs over the place.
Likewise, the similar functions in WorkspacesViewBase subclasses take
now MetaWindow arguments too.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
We don't really need this step as a separate method since all
implementations are supposed to be created and shown immediately. This
also ensures that we have items to show in all subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=735976
The enums values of geoclue have gaps in them (so more levels could be
added in future) but enum values of settings don't have such gaps so we
gotta translate between them.
Since desrt says that enums as integers in gsettings are bad, we now
treat accuracy level settings as string.
This fixes the recent regression of geoclue only allowing geiop level
accuracy to apps.
https://bugzilla.gnome.org/show_bug.cgi?id=736479
Since commit e04e507659, we will already get the right icon for the
submenu arrow, so we must not mirror it again. However we do need to
take the text direction into account for the rotation now (but that's
not actually too bad - the resulting code gets quite a bit easier).
https://bugzilla.gnome.org/show_bug.cgi?id=736343
Trust the heuristics in shell_app_can_open_new_window() to get it right
more often than not, and add an appropriate check in activate(). This
makes the behavior consistent with the dash, e.g. we will try to open
a new window (and show the corresponding animation) for apps that don't
have a "New window" item in their dash context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=736329
Commit 9e5704b introduced a regression due to a sloppy mistake not
making actors reactive on animation out.
Fix that making actors reactive when animating out as well.
The current code only works for enabled extensions, which means
that extensions that were marked OUT_OF_DATE cannot be enabled
without a restart when disabling the version check.
Fix this by reloading all extensions while making sure to only
enable any extensions when we're supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
Currently we consider the last item animating being the last actor of
the list, but that's wrong since the last item animating depends on the
distance between the source actor and the original position of the
animated actor.
Take that into account to check the last item of the animation.
The code that cleaned up when a background actor was destroyed tried to access
the Background as backgroundActor.background._delegate but when the destroy
signal is emitted, the MetaBackgroundActor was already disposed and
backgroundActor.background NULL.
The rewrite of Mutter's background code (see bug 735637) requires
corresponding changes here - we no longer need to layer multiple
MetaBackgroundActors together.
The general strategy is that a BackgroundSource object is created
per GSettings schema, and keeps either one Background/MetaBackground pair,
or, for animation, a Background/Metabackground pair for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=735638
When you open or close a PopupSubMenu the arrow icon rotates, but
the code previously assumed that the starting angle was a multiple
of 90. If you click the submenu fast enough the rotation could overlap
with the previous rotation and you'd get something that wasn't a multiple
of 90.
Now we ensure that the ending arrowRotation angle is always a multiple
of 90 regardless of what the starting angle is.
https://bugzilla.gnome.org/show_bug.cgi?id=728927
Although the actor are with opacity 0, they were reactive, so the if the
user quickly make a click on the grid while animating it can launch an
app accidentally.
To avoid that make the actors non reactive while animating.
Show the on-screen keyboard if gnome-settings-daemon requests that it
should be shown, such as when using a touchscreen input device. Do this
in addition to monitoring the accessibility setting for the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=702015
Commit 12845f0eef reset translationX to 0 to fix the slide-in
animation of the dash when dragging a search result, but 0 is the
wrong value for the thumbnail slider - the next time it will be
shown, it will just pop up instead of sliding in due to translationX
already being at its target value.
Fix this by making _updateTranslation take the actual visibility into
account and call that to set the correct translation in dragBegin.
Controls are slided in by animating translationX from the actor's
width to 0; however as _updateTranslation() will skip the animation
when the property is already at its target value and 0 happens to be
the initial value of translationX, the initial animation is skipped.
Fix this by initializing translationX to undefined, which will always
differ from a valid target value.
The comment is right, updating the translation should be deferred
to pageEmpty, or else overview controls will just pop up instead
of sliding in. So revert that part of commit 6a7fa52879.
Providers that need drag-and-drop behavior can implement this via the
createResultObject() hook (as the app search provider already does), no
need to duplicate that code in the generic result objects
(ListSearchResult already does not implement DND).
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design mockups, animate the icons on AllView, FrequentView,
Dash and Search to zoom out when opening a new window of the app or when
the app is not running and the user execute it.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Given that we animate indicator in, it makes sense to animate them out
as well.
Also make possible animating indicators between view changes as well.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design decision, we want to animate AllView and FrequentView
when opening and closing with a swarm spring form.
This involves a few changes needed to allow that, since from some time
now, we are animating page changes in viewSelector, using only a fade
transition. However now we want to let appDisplay and iconGrid apply its
own animation.
For that we special case the change to and from apps page on
viewSelector to let appDisplay to animate its own items, using and API
on appDisplay which at the same time uses an API on iconGrid.
Thanks Florian Müllner for the debugging work
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Add a new animation to folder view based on designers mockups that
emulates pulsating icons.
The code on iconGrid is though to work well for the upcoming patches to
animate AllView and FrequentView.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
If you turn on natural scrolling, instead of swiping up, you need to
swipe down, which is bizarre. Just accept any type of scroll and have
them contribute to the delta.
https://bugzilla.gnome.org/show_bug.cgi?id=734874
This reverts commit a84fb99c0a.
This commit didn't make the OSK fully operational yet on Wayland, and
caused the double emission of key events on X11 due to the OSK keys
receiving first touch events from the passive touch grab, and then
emulated pointer events from event selection after the touch sequence
was rejected in the grab.
When we make a better effort at handling touch events just once on X11,
this commit can be reapplied and remaining wayland OSK support resumed
from there. In the mean time, this patch is better reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=735681
Commit bbfa616f27 renamed _ignoreRelease to _ignoreUntilRelease
in some places, but not others, which broke GrabHelper.ignoreRelease().
Complete the name change to fix the fallout (e.g. app launcher menus
closing on button release).
The code from PanelMenu.Button assumed menus would open below their
source actor, making KEY_Down a good choice; however with the new
generic code, we should base the key used on the actual menu position.
https://bugzilla.gnome.org/show_bug.cgi?id=735614
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
Since mutter commit 527c53a2a0582eba, MetaWorkspace::window-removed
is emitted *before* MetaWindow:workspace is updated, so the test
whether the removed window should still be on the workspace in
question will always return true.
Assume the test is no longer necessary nowadays to fix this very
obvious regression.
https://bugzilla.gnome.org/show_bug.cgi?id=735608
Currently we are removing tweens of the button and border, but not from
the title. That causes the title to be in wrong positions sometimes when
dragging windows on the overview, given that the slider is moving and
therefore the windows + overlay are moving too.
To avoid that, remove tweens of the title as well.
The code that loads SHELL_BACKGROUND_IMAGE, which is used to load the
performance background was loading it in WALLPAPER mode, not ZOOM
mode. Zoom mode is what we use for the actual GNOME defaultiwallpaper
and what we want to test: the background will be scaled except when
the resolution matches the 2560x1440 default backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=735385
Users can now toggle geolocation off/on from privacy panel of
gnome-control-center so we don't need to clutter the menu with a
settings that most users won't touch most of the time.
https://bugzilla.gnome.org/show_bug.cgi?id=731122
The scale passed to _updateChildrenScale is exclusively computed from
properties, so it can be moved into the function itself - as the scale
now becomes a mere detail, rename to a more appropriate _updateIconSizes
at the same time.
The existing code broke when commit 792b963bda changed the custom
result actor hook to return an object instead of an actor - stop
trying to go through a _delegate to make it work again.
Commit 14ceb10555 changed the "Open Calendar" item to open the
"recommended" calendar application rather than the default one to
avoid problems with MIME subclassing (namely falling back to the
default text editor when no calendar app is installed).
With this change however, the application launched does no longer
necessarily match the one configured in Settings, which is unexpected.
To avoid both problems, use the default calendar application again,
but only if it is in the list of recommended applications.
https://bugzilla.gnome.org/show_bug.cgi?id=722333
We need to put the actual actors in the history, not just the labels,
otherwise all emptyLine (which are not messages but are not empty
either) and all lines with a timestamp will get stuck in the scrollback.
https://bugzilla.gnome.org/show_bug.cgi?id=733899
Search providers that should be disabled by default come with
a DefaultDisabled=true key in their keyfile, and are enabled
with the "enabled" whitelist, not with the "disabled" blacklist.
https://bugzilla.gnome.org/show_bug.cgi?id=734110
Performance testing was producing inconsistent values at different
times in the day since the GNOME default background is animated and
sometimes has a single layer, and sometimes two blended layers.
So we have consistent numbers, install a simple animated background
with GNOME Shell that has 40-year long transition ending in 2030,a
and set an environment variable in gnome-shell-perf-tool so that the
background is override with that background. (The background depends
on files installed by gnome-backgrounds; we assume that the person
running performance tests is doing so within the scope of a full
GNOME install.)
https://bugzilla.gnome.org/show_bug.cgi?id=734610
All derived classes are already checking explicitly for action names
(FOO and FOO_BACKWARDS). mutter used to have a META_KEY_BINDING_REVERSES
flag for keybindings which required special handling of "shift"+FOO as
FOO_BACKWARDS, but this has been removed now, so this special handling
is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
When this flag is set on a MetaKeyBinding, mutter will know that
the keybinding has an associated reverse keybinding triggered with
the shift modifier. However, an undesirable side-effect is that
gnome-control-center keyboard panel does not know that this 'shift'
is reserved for these reverse keybindings and cannot detect
conflicting bindings in this case.
This 'reverse' logic can now be handled at a higher level (in gcc keyboard
panel) so this commit removes it from gnome-shell so that they do not
conflict.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
Now that mutter gives a way to check if a MetaKeyBinding was marked as
'reversed' or not, gnome-shell does not have to hardcode that a
MetaKeyBinding using a shift modifier is reversed, it can directly check
if the appropriate flag is set.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
We were setting the value of adjustment on size changes, but we weren't
changing the page value, so adjustment and page value was not in sync.
To fix it, make sure adjustment of the view is in sync with the page
value.
https://bugzilla.gnome.org/show_bug.cgi?id=734680
Since these settings are now going to be accessed by
gnome-control-center as well, its more appropriate for them to live in
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
Having the on/off setting be backed by a boolean in dconf makes sense
anyway but this is mainly to be able to remember the max accuracy set
before user disabled geolocation so that when they enable it next time,
we have the max accuracy level on same value as before.
There hasn't been a real need for this but now we are about to add
geolocation settings in control center and it'll be easiser for
control-center to simply toggle a boolean property rather than to have
to know about and deal with accuracy levels.
Later we might also want to add accuracy level settings to privacy panel
so keeping the accuracy level setting around still. However we no longer
support 'off' accuracy level as the new boolean property covers that.
This also implies that we no longer track available accuracy level,
which made the code a bit hard to follow/maintain.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
The zooming animation of the windows looks nice when animating
from the workspace display page, but looks weird from other pages
like apps page or search page since the windows come from nowhere
with an initial position not known to the user.
Instead of that just fade the desktop with the windows in its
original position.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
Currently we are overriding the explicit calls to slideIn
given that it's called also with the signal of showing overview.
It was necessary because of the bug that previous patch fixed,
so now we can just delete that.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
The slide of thumbnailWorkspace is shown when entering overview,
connecting to the same signal that creates the thumbnails, the showing
signal of overview, but, to make the slide animation we need to know how
much width the slider has. To do that we ask the thumbnailsWorkspace
about its width, but given that it connects to the same signal it could
ask the width without having created the thumbnails yet, so reporting a
width of 0 and confusing the slide animation.
Currently it works because gjs calls the callbacks following the order
of the clients connecting that signal, and the thumbnailsWorskpace is
connected before the slide ones.
To avoid that we allow to request the preferred size of the
thumbnailsBox at any time with any number of thumbnails. The only thing
required is to make sure the porthole is accessible when requesting the
preferred size.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
We were calling twice showPage() with the correct page, here and in
show() / zoomFromOverview given that _resetShowAppsbutton was called
from the signal 'showing' of overview. Given that the call to
_resetShowAppsbutton is only actually used when hiding the overview we
can actually put the checked state of the button to false when animating
from overview so it shows the workspace page, causing the same behavior
of _resetShowAppsbutton without all the shenanigans of resetting when
the hiding overview signal is triggered.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
