Currently when a preference widget fails to load, we throw a raw
backtrace at the user. While that is undoubtedly useful information
for extension developers and bug reports, it is gibberish to most
users and hardly the first thing they should be exposed to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/193
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This is actually papering over bugs in toolkits. On X11 the Xserver will
send crossing events when the stage input shape changes. As those go
end up ignored in GTK+, this warp call aims (and randomly manages) to send
a motion event that wouldn't go unlistened by the drag source window (the
one holding the grab).
This bug actually manifests in other ways, eg. by changing the window
beneath the pointer with alt-tab while DnDing. This should be fixed
altogether in the client side.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This gdk_display_sync() call was added in commit a40daa3c22 so the alt-f2
dialog is able to spawn commands that trigger grabs on startup (eg. xmag/
xkill).
This seems worthwhile to do only on the X11 backend, and handling it in
mutter backend code seems cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
Allow notifications to set a x-gnome-privacy-scope hint, with values in
['system', 'user']. If all the notifications in a particular source hint
that their privacy scope is ‘system’, don’t hide the notification
details on the lock screen.
This is aimed at fixing the particular case of power notifications: they
contain information which is not private to the user (it relates to the
system: battery state or AC state, which is obvious to anyone who can
see the machine), so hiding the details of a power management
notification when the screen is locked is pointless.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/issues/726
Most often it is a bug if the condition part of a for-loop contains the
assignment operator rather than the comparison one, so tools rightfully
emit a warning.
Clarify that the assignment is intentional in this case by adding
parentheses.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
Just like the "in" operator in the previous patch, "instanceof" has
a lower precedence than negation, resulting in the nonsense condition
of "true instanceof BaseIcon".
Add parentheses to get the intended behavior.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
The "in" operator has a lower precedence than negation, so we are
actually testing whether the favorites map contains "false".
Add parentheses to get the intended behavior.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/375
The Magnifier class uses a small subtree of actors to track the
current cursor's position and sprite. Specifically, it uses the
deprecated ClutterTexture to paint the cursor sprites.
Add a new, very simple ClutterContent implementation to track the
cursor sprite, and replace the ClutterTexture by a ClutterActor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/371
The last patch in the series, this one adapts StShadowHelper
to received a CoglFramebuffer. This is where we first touch
JavaScript with Cogl types, and as such, it depends on the
latest Mutter. Earlier versions of Mutter didn't have its
Mutter-Clutter GIR to generate types for various Cogl types.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
With the recent port to JS6 classes, the trailing
comma after functions in the syntax of classes has
been removed.
However commit c2961f21 accidentally reintroduces
one trailing comma after a newly created function,
leading into g-s throwing an exception and not
starting anymore.
Therefore, remove this trailing comma to solve
this problem.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/366
Besides the device grab on the drag device, also set up a captured-event
handler to catch other devices (except the keyboard) while the DnD
operation is ongoing. This makes DnD operations exclusive to others.
Also, disallow it in less aggressive ways if maybeStartDrag() gets called
while there is a current draggable.
This might definitely be nicer (eg. having other grabbed devices emit
leave/end events), but can't be done without major surgery to Clutter.
In the case where the draggable has an actor of its own, state could be
left broken when dragging on a place that would not accept the DnD op.
After button release, drag state is set to "cancelled" and the animation
begins. After the animation is finished, the drag actor would be destroyed
before disconnecting from its destroy handler.
Within the destroy handler, the grab would be undone but drag state would
be left on "cancelled" state for subsequent operations. This results in
DnD oddities and stuck grabs.
In order to fix this, double check in the actor destroy handler that we
are actually dragging before setting the "cancelled" state.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
Instead of fetching the CLUTTER_POINTER_DEVICE device. It will
be wrong if drags get initiated from tablet pointers. This allows
for DnD operations to be started, moved, and more importantly
finished through tablet devices.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/540
Whenever the AllView needs (re)populating, we used to do one general
g_app_info_get_all() to get all GAppInfo, plus one per app folder in order
to check the ones that fall within that category. This calls results in a
fair amount of I/O blocking the main loop.
In order to ease this, keep the GAppInfo list around in AllView, and make
the AppFolders use it when figuring out the contained apps. Since reloading
the AllView results in AppFolders regenerated from scratch, the app info
list is ensured to be up-to-date for any later change within the AppFolder
(eg. through the GSettings key changing).
As the list was already filtered in the first place, we can also remove
the try{}catch() in AppFolder in order to discard desktop files with
invalid encoding.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/832
When connecting to a Wi-Fi router that supports the WPS button method
(PBC, push button connection) the user can simply press the button on
the router. Show an explanation in the PSK prompt when this is
possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/329
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When using dynamic workspaces, it is possible to try to change to a
non-existent one if the user defines hotkeys for changing to desktop
1, 2, 3... This case is not detected, and gnome shell shows an error:
JS ERROR: TypeError: workspace is null
actionMoveWorkspace@resource:///org/gnome/shell/ui/windowManager.js:2130:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
_showWorkspaceSwitcher@resource:///org/gnome/shell/ui/windowManager.js:2104:13
wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
This patch adds a check before trying to change the workspace, to avoid
switching to a non-existent one.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/365
When an InputSourceIndicator is destroyed, the InputSourceManager it was
connected to could (and probably will) outlive it (since the manager is
a singleton). If the InputSourceManager emits any subsequent signals,
the callbacks from the finalised InputSourceIndicator could be invoked,
and will reference finalised objects.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Otherwise the user object could outlive the dialogue, emit a subsequent
signal, and the callback from that signal could reference finalised
objects/widgets from the dialogue. The likely mechanism for the user
outliving the dialogue is caching of user objects within
libaccountsservice.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Rather than explicitly destroying the session after calling close(),
destroy it from the `closed` signal handler.
This also means we can make the method internal.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
In case there are any internal ways the dialogue can close itself
without calling its own close() method, it’s probably better to do all
our cleanup on a handler for the `closed` signal instead.
This should introduce no functional changes except ensuring the
polkitAgent cleanup is always done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
Otherwise the session could outlive the dialogue, emit a subsequent
signal, and its callback would reference finalised objects/widgets from
the dialogue. The PolkitSession object is implemented by
libpolkit-gobject, so we have no guarantees about its reference counting
— the session object could keep itself alive in another thread, or be a
singleton. In all likelihood, the session hangs around for longer than
the dialogue due to differences in when the two objects are garbage
collected.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
This avoids the following warning sometimes happening later:
JS WARNING: [resource:///org/gnome/shell/ui/search.js 701]: reference to undefined property "searchInProgress"
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
The built-in calendar isn't meant to replace a full-fledged calendar
app, which is why clearing event messages only hides the event in
gnome-shell rather than deleting the actual event. This has turned out
to not be overly useful and often confusing - it creates a discrepancy
with visible events in apps, isn't revertible in a non-obscure fashion
and non-obviously limited to the current date.
As we are considering moving events out of the message list and back to
the calendar, it looks like a good time to remove that ability and keep
notifications as the only removable messages.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
We currently deliberately avoid chaining up in derived policy
constructors to not override properties with their defaults.
That's a neat trick that will stop working when porting to ES6
classes, as chaining up is necessary to actually initialize the
object there (including "this").
Address this by turning all properties into (overridable) getters
that are backed by private properties by default.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/350
The _createPolicy() method of a subclass usually depends on some
constructor parameters that need to be set before chaining up to
the parent. This works fine with Lang.Class, but will break with
ES6 classes, as "this" is only initialized after chaining up.
Prepare for this by not creating the policy in the constructor,
but when it is first accessed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/350
Check via Polkit if the current user is actually allowed to enroll
devices before trying to do so. If not, show a notification that
explains that a system administrator needs to authorize the device.
Clicking on the notification will guide the user to the thunderbolt
control center panel. Before this patch, when the current user was
not allowed to enroll a device a polkit dialog would pop up which
is confusing because it did not contain any information why it was
shown. This patch implements the behavior as designed (see [1],
section "Multi-user environments").
[1] https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess
Since commit 5fb8d4f730, a NotificationMessage's notification property
is reset to null when the notification is destroyed. However at that
point we still have connected signal handlers around that we'll try
to disconnect later.
Avoid the warnings by disconnecting and resetting the handler IDs at
the same time as the notification.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/308
In contrast to generic animated icons, it is reasonable to expect
spinners to be invisible while inactive. Implement that behavior
in the new Spinner class and optionally animate the transitions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/316
When `ibus restart` runs, InputMethod.enabled is changed to false
and no longer enable ibus but 'enabled' and 'disabled' signals
are not used in the current IBus clients and it's good to delete
the member simply.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/295
If the session mode doesn't allow access to Settings, the language
menu should respect that and not expose the "Region & Languages"
panel. Using the dedicated method instead of manually constructing
the menu item takes care of that and makes for less code.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/780
The picked target actor may be destroyed (e.g. hover style change
resulting in the ClutterTexture to be destroyed). If we don't handle
this, GJS will abort when it sees the exception caused by Javascript
code trying to access the destroyed target actor.
To handle it, listen on the 'destroy' signal on the target actor, and
repick, so a valid actor is passed to the next motion callback.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/632
When a fullscreen application is focused,
toggling the overview via hot-corner is disabled,
even when the overview is currently visible.
This only makes sense, when the overview is
hidden to not to disturb the behaviour of the
fullscreen application, but leaves an
inconsistency when the overview is visible since
it should work there like when a non-fullscreen-
application is focused.
So, always allow hiding the overview using the
hot corner when the overview is visible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/429
The `GetWindows` method gives access to the list of windows for each
application with some of their properties, so utilities such as dogtail
can pick the window of their choice to interfere with using the provided
window id.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/326
Add a D-Bus API that allows the API user to introspect the application
state of the shell. Currently the only exposed information is list of
running applications and which one is active (i.e. has focus).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/326
The intention of commit 4dc20398 was to disable unredirection while
banners are shown, but the ::done-displaying signal currently used for
re-enabling unredirection is only emitted under some circumstances, so
it's possible that unredirection is left disabled indefinitely, whoops.
Fix this by tying disabling unredirection explicitly to the lifetime
of the banner actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/799
The only reason for `vfunc_paint` and `vfunc_pick` existing was to
implement a culling optimization. Although that optimization actually
made performance worse than none at all because it forced the painting
and picking cycles to spend more time calling into JavaScript.
Turns out we don't have to choose between native code and culling though.
Just reimplement the culling using native ClutterActor functions and we
get the benefits of both.
Performance on an i7-7700:
Moving the cursor over the icon grid:
Before: 70% CPU, 5.5ms per frame
After : 60% CPU, 4.5ms per frame
Scrolling the icon grid:
Before: 60% CPU, 4.4ms per frame
After : 50% CPU, 3.3ms per frame
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/174
Destroy the DashItemContainer's child from the same handler as the tooltip. This
will prevent invalid reads when the item is destroyed while its quicklist is
still open.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/781
Since commit 551e827841, we don't always pass a callback parameter.
However passing it on as undefined to ibus doesn't work, as gjs doesn't
accept that as a valid callback value and throw an error. As a result,
we can end up with no layout selected in the keyboard menu and an "empty"
indicator. Fix this by explicitly passing null if no callback has been
provided.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/293
Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
The pending-charge state means AC power is on but the battery is not
being charged. This can happen because its charge is above a certain
threshold, to avoid short charging cycles and prolong the battery's
life, or because the PSU is not powerful enough to charge the batteries.
Instead of lying to the user about something being estimated, we should
simply tell the truth and set the label to "Not Charging".
Closes: #701.
When we started to only show a single caption at a time, we allowed
title captions to be wider than their corresponding window preview.
But while overlapping neighboring previews is fine, we shouldn't
allow the captions to leak outside the workspace area itself and
overlap unrelated elements like workspace switcher or dash.
This partly reverts commit b3b30f239d.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/214
Instead of defaulting to a natural scroll behavior,
have the workspace switch action use the natural-scroll setting
in org.gnome.peripherals.touchpad to determine the correct
direction of travel when swiping. 4 finger swipes will then
match the behavior of the rest of the UI.
Reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/516
While this sounds counter-intuitive, the image-path hint value might also
be used with URIs or icon names.
As per freedesktop standard:
The "app_icon" parameter and "image-path" hint should be either an URI
(file:// is the only URI schema supported right now) or a name in a
freedesktop.org-compliant icon theme (not a GTK+ stock ID).
Thus the image-path hint should also be parsed as it happens for the
app_icon.
Reuse same logic, by falling back on _iconForNotificationData with the
hint value.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/285
We have a callback that will call close() when the notification is
destroyed, and a callback that will call destroy() on the notification
when the message is closed.
Currently, if the notification is destroyed we'll execute our callback
that will call again destroy() on the notification. That's bad
practice in general, and it also has the side effect of resetting the
destroy reason.
This commit avoids re-destroying the notification by dropping the
notification reference on destroy.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
Differently from the fd.o notifications, Gtk notifications do not
have a mechanism to update themselves. Instead, when a new
notification is received for an ID already known to the notification
daemon, the old notification is dismissed and a replaced with a new
one.
Currently though, there is no way to distinguish a notification that
was dismissed because of an user interaction, or because it was
replaced. That is an useful piece of information, so add a new value
to the NotificationDestroyedReason enum to account for it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/258
When gnome-shell receives the signal of 'set-content-type' from ibus,
gnome-shell calls KeyboardManager.holdKeyboard() and
KeyboardManager.releaseKeyboard() and the functions change the current
input focus in GNOME Xorg and it could result in closing a popup window
which has a password entry by focusing on the entry.
The solution is to stop to call the APIs on 'set-content-type' signal.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/391
We don't usually show notification banners while the monitor is in
fullscreen, but when we do - the notification is urgent - we should
actually show the banner, even if the top-most window is unredirected.
To achieve that, disable unredirection while the banner is showing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/430
The `reactive` property of icon actors was being restored multiple times
over the course of the pulse animation, all at slightly different times
as each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a pulse animation, limiting its smoothness and performance.
The solution is to not toggle the `reactive` property in the pulse
animation at all, which avoids incurring multiple full stage relayouts.
As a bonus, this means the icon under the cursor pulses with the correct
selection highlight, appearing more seamless and responsive.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/261
The `reactive` property of icon actors was being restored 24 times over
the course of the spring animation, all at slightly different times as
each icon finished animating at different times.
The problem is that toggling `reactive` on an `StWidget` incurs a style
change of the `insensitive` pseudo class, and style changes would quickly
queue relayouts incurring full stage reallocation. This occurred many times
during a spring animation hogging the CPU and limiting the frame rate.
The solution is defer and batch the cleanup for all icons until after the
last icon has finished animating. This way the CPU impact of the style
change and stage relayout isn't felt during the animation so the frame
rate remains higher and smoother. The overall CPU usage of the animation
is also reduced as the remaining relayouts are much more likely to be
grouped into a single frame.
Icon spring animation performance on an i7-7700:
Before: 83% CPU and 47 FPS
After : 78% CPU and 54 FPS
which is about a 22% increase in performance per clock (FPS/CPU).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/253
The switcher popup is a large, mostly transparent actor that
should cover all the clickable area of GNOME Shell. In Clutter
terms, it should cover the whole stage.
By binding it to the primary monitor, the Alt+Tab behavior
becomes a bit inconsistent. For example, by not hiding when
clicking at empty spaces at other monitors.
Fix that by binding the SwitcherPopup to the whole stage,
and not only the primary monitor.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/647
