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
Support was added to Mutter to allow it to trigger a restart
to allow for restarts when switching in or out of stereo mode.
Hook up to the new signals on MetaDisplay to show the restart
message and reexec. Meta.is_restart() is used to suppress
the startup animation.
This also allows us to do 'Alt-F2 r' restarts more cleanly
without a visual flash and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
Add an option for windows created with Scripting.createTestWindow()
to continually redraw themselves; this is for testing performance
of application updates.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
We currently replay events that should start a search to the search
entry, which is fairly dodgy. Synthesize a new event with the correct
source actor instead, which is a bit less evil.
If an active grab on pointer events happens during multi-touch operations,
all non-pointer-emulating touches will be muted. This may leave the
Clutter.ClickAction incomplete if triggered by one of those sequences,
just to have a gesture take over and trigger a compositor grab, which would
leave the capture-event handler stuck eating events.
So listen for grab-op-begin from the display, and ensure the action is
released if such grab begins.
and the capture event handler stuck.
When returning to the desktop from overview we always show the
workspaceDisplay, given that is which have the windows clones to allow
animations.
The problem becomes when previous that we were at some other
page, like Search or AppDisplay. The problem is that when showing the
workspaceDisplay the windows are repositioned. That's wanted except
when returning from overview, since that causes unwanted animations
of the windows.
To avoid that just not reposition the windows if leaving the overview.
We don't normally hit the code in scripting.js to print metrics
because shell-perf-tool bypasses it, but there was a left-over
in the code that no longer works. Also add in the units to the
output.
https://bugzilla.gnome.org/show_bug.cgi?id=732349
Listen to changes in connectivity, and ask our helper to authenticate
when needed.
We don't have a URL to connect to yet (we will have when
the new NM API lands), so we use the default of trying
www.gnome.org (which is also more reliable because we can
recognize when the login is done)
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Icons inside the menu are updated only for device state change,
but for the main device they also depend on connectivity (which
is a global property).
Add a public method to force an update of the icon, and call it
when connectivity changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726401
They are different properties, they deserve different syncs.
Especially because a full allocation cycle sets both anyway, so
we should save some cycles this way.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We already have the width and height information cached in JS,
let's avoid going through gjs-gobject-clutter to retrieve them
again. As a plus, with normal properties the optimizer should
be able to generate better code.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We must remove the old image from the cache, not the new one.
This was causing a leak of old (and expensive) background
images, and was causing errors at the end of animations, trying
to destroy the animated background.
We translate 'On' to available accuracy level but if available accuracy
level later changes, we don't update available accuracy level accordingly
and hence limit the accuracy of apps.
E.g if available accuracy level is 'city' and geolocation is enabled,
the max accuracy level would be 'city' and apps can't get higher than
that. Now if user plugs in GPS, the available accuracy level will change
to 'exact' but without this patch max accuracy level will remain to be
'city' and apps will not be able to use the GPS.
https://bugzilla.gnome.org/show_bug.cgi?id=731882
The code currently tries to use Meta.KeyBindingFlags.REVERSED. Since
this constant is |'ed with Meta.KeyBindingFlags.REVERSES, gjs silently
ignores the unknown flag.
https://bugzilla.gnome.org/show_bug.cgi?id=731619
Commit 5d00c1a5ee moved app folder popups to GrabHelper - for some
reason, the line that ensures the current behavior of only considering
events inside the app picker to dismiss popups got lost ...
As clicks outside the app picker should still be handled normally
while clicks inside should dismiss the popup, we cannot make full
use of GrabHelper. However using it at least for focus handling
fixes some minor details we are getting wrong, for instance not
restoring the previous focus after dismissing a folder popup.
Commit 6c2f3d1d17 moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.
Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
https://bugzilla.gnome.org/show_bug.cgi?id=695487
The 0x0 dummyCursor works well when the menu pops up directly underneath
the pointer (e.g. when triggered by right-clicking the titlebar) or by
keyboard, but not when triggered by the menu button - the menu does not
point to the center of the button's bottom edge, and unless the user
keeps holding the mouse button while moving into the menu, the menu will
be dismissed immediately on button release.
Address these issues by using the button geometry to overlay the window
button with an appropriately sized actor that acts as a proper sourceActor,
to make the window menu behavior consistent with other shell menus.
https://bugzilla.gnome.org/show_bug.cgi?id=731058
Having the full geometry of the menu's source button (if any) will
allow us to address several misbehaviors of window menus, so use
that instead of show_menu().
https://bugzilla.gnome.org/show_bug.cgi?id=731058
When the pointer leaves the notification area, we queue a timeout to
hide the notification after a little while. If the user is hovering over
a notification and clicks the X button to close the notification, we will
destroy the notification, which causes a "pointer left" event on the
notification area. This queues a timeout which erroneously fires after
the next notification in the queue shows up.
The code and state machine are too complex to properly make sure this
timeout doesn't fire when there is no notification up next, so instead
just clear it when showing a notification to make sure that any
previously queued timeout doesn't apply to us.
https://bugzilla.gnome.org/show_bug.cgi?id=731118
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
It is a bit odd to request AM/PM format when the locale selected
by LC_TIME lacks the concept. We ignore the format setting in that
case elsewhere and assume 24-hour format, let's do the same for
chat timestamps for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=728271
When workspaces are disabled by the session mode, all workspace
related actions don't make sense. Worse, the "Move to Workspace ..."
actions allow sending windows into a nirvana with no means to
get them back.
https://bugzilla.gnome.org/show_bug.cgi?id=730653
Starting keynav into the active page is handled from a key-press
handler on the stage, however we should not "start" keynav when
we are already navigating elsewhere - the latter can happen when
keynav fails (for instance because the focus is trapped inside an
open app folder or at the end of the dash), and the event bubbles
up to the stage. So make sure to only handle the event to actually
start keynav, to not interfere with the normal navigation handling.
Thanks to Carlos Soriano <carlos.soriano89@gmail.com> for the
debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=726760
The fallback app-menu in GTK+'s client side decorations obviously
uses the GTK+ theme rather than the shell one; update the style
of our own fallback app-menu to resemble that style.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
We now allow "appmenu" in the button layout to make synchronizing it
with GTK+'s client-side decorations easier, but as some people tweak
their settings to get in-window app menus even when using the shell,
actually pop up the app menu when the button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
The optional label support introduced in commit af063dc2f2 broke
the centering of separators, as the label still adds additional
spacing even when empty.
Properly hide the label actor in that case to fix the alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=730753
When a monitor is removed, the OsdWindow for that monitor may process
the monitors-changed signal before OsdWindowManager does (which will
remove the OSD). If that happens, we will currently try to access
an invalid monitor; check for this to avoid a couple of warning.
When switching between alternatives in AltSwitcher, the currently
visible child is replaced with the alternative. If the original
child has the key focus when it is removed from the stage, the
focus is lost. Detect this case and manually move the focus to
the new child.
https://bugzilla.gnome.org/show_bug.cgi?id=727259
When dragging a window preview from a non-primary monitor onto a
workspace thumbnail, the window is moved to the primery monitor
first before changing its workspace. However when dragging the window
between thumbnails to create a new workspace, it is kept on its current
monitor instead. This is not only inconsistent, but outright confusing
with the default 'workspaces-only-on-primary' setting, as the newly
created workspace is immediately removed again.
https://bugzilla.gnome.org/show_bug.cgi?id=683819
