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
Currently the indicators are a BoxLayout inside a BinLayout in AllView.
BinLayout doesn't have any size constraint, so if the indicators request
a bigger size than AllView the entire overview is grown, causing the
overview to go crazy.
To avoid that, create an actor for the page indicators that request as
minimum size 0, and as a natural size, the sum of all indicators natural
sizes. Then we clip_to_allocation, so it doesn't grow more than the
parent.
https://bugzilla.gnome.org/show_bug.cgi?id=723496
If the application reports itself as single window (through
an explicit indication in the desktop file or some heuristics),
not show a "New window" item that doesn't actually open a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=722554
Both Panel.ActivitiesButton and its parent class Panel.MenuButton would
attempt to connect their own _onEvent() function to Clutter::event,
which counterintuitively was connecting the child class' _onEvent()
function twice.
So, actually chain up on the signal handler, and don't connect twice
to the signal. Both methods were calling this.menu.close(), so only
do that on the parent class handler, since we're chaining up and doing
the right thing now.
https://bugzilla.gnome.org/show_bug.cgi?id=733840
We don't need to wait to until the stage window is mapped to take
the modal grab, because that code now runs in a startup-prepared
signal handler, which in turn runs some time after the mainloop
has started and well after the stage window is mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
The grab would previously just consume the button release, while propagating
motion events, possibly down to clients in wayland. This would produce
inconsistent streams there.
On pointer events, the inconsistency would just be having clients receiving
events with the button 1 set in the mask, with no implicit grab. When touch
events are handled, this would be more hindering as the client would receive
touch_motion events with no prior touch_down nor later touch_up, something
never supposed to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
The animation is the same for modal dialogs, but it is now
run for non modal dialogs too (matching the new behavior on
show).
In addition, we run a destroy animation for normal windows,
if they use CSD (there are technical limitations that prevent
running animations after destroy on server decorated windows)
https://bugzilla.gnome.org/show_bug.cgi?id=732857
Handle touch events, so that an interacted button locks to a single sequence,
but multiple sequences are free to interact with multiple key buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
The long press code has been refactored so it can be used on both pointer and
touch events, and the click gesture has been made to account for button=0.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
No sequence checks are done, these UI elements promptly trigger a grab that
will cancel ongoing touches and redirect later ones somewhere else, so that
works as a barrier to multi-toggling.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
This adds a table with mappings for GNOME apps that have recently
renamed their desktop files, and uses that to update the desktop names
saved in user settings with the new values.
https://bugzilla.gnome.org/show_bug.cgi?id=729429
Currently to know how many results we could show for GridResults
we use the width of the bin containing those results. Since it's
expanding it shouldn't be a problem. But it becomes a problem when
no results are displayed, thus the container becomes hidden and
it losts its allocation.
In the next introduction of terms in search we call again
maxDisplayedResults but it doesn't have allocation yet, and therefore no
results are displayed (currently a bug on IconGrid makes the min size =
one icon, so actually we show one and only one icon in this case).
To solve that use the parent container which contains the search results
of all providers or the text label with not displayed results, so it
always have the real available width to calculate maxDisplayedResults.
Thanks Alban Browaeys for the debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=732416
Unlike for the main app view, where we only move the key focus once the
users starts navigating, the key focus is moved immediately when opening
a folder popup. This is unexpected, so make app folders consistent with
the main view.
As arrow keys will not work while the container itself has key focus, we
handle those explicitly by translating them to TAB_FORWARD and
TAB_BACKWARD respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=731477
