This reverts commit e23c2ffecc.
The patch was intended as a cleanup but accidently removed the setting of the
event base, breaking the swap event handling.
With the event base setting removing the other code isn't much of a cleanup so
just revert it.
Send EOS to the complete pipeline instead of only to our own source.
When there are multiple sources in the pipeline (for example when we also
record audio), the pipeline will send the EOS to all sources in order to
shut down the complete pipeline.
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 ...
Some entries have untranslatable descriptions/summaries. This means that
when running dconf-editor, some entries will get a translated descriptions,
and a few will not.
https://bugzilla.gnome.org/show_bug.cgi?id=728170
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
