Whether people love or hate the hot corner depends in large extents
on hardware sensitivity and habits, which is hard to get right
universally. So bite the bullet and add an option to enable or
disable hot corners ...
https://bugzilla.gnome.org/show_bug.cgi?id=688320
A window being unmanaged can cause the ShellApp to be removed from
the ShellAppSystem, which if we are unlucky is the app's last
reference, causing it to be disposed and freed. It would be bad if this
happened before we finished handling the signal.
Use g_signal_connect_object to ensure that a reference is held to
the ShellApp for the duration of the signal handler, delaying its
last-unref.
In particular, when a signal handler calls _shell_app_remove_window(),
there is a brief period for which ShellApp breaks the intended
invariant (see !497) that app->running_state is non-NULL if and only if
app->running_state->windows is also non-NULL (non-empty). Freeing the
ShellApp at this point would cause a crash. This seems likely to be the
root cause of <https://gitlab.gnome.org/GNOME/gnome-shell/issues/750>,
<https://gitlab.gnome.org/GNOME/gnome-shell/issues/822> and
<https://bugs.debian.org/926212>.
Signed-off-by: Simon McVittie <smcv@debian.org>
Compare painting/geometry of old and new paint nodes, so it's ensured to
be only emitted on actual style changes. Emission still must be propagated
through to children, though.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1153
At the point it is disabled, it has got signal handlers connected but
this._workspacesView is uninitialized. This triggers:
(gnome-shell:3993): Gjs-WARNING **: 18:49:53.281: JS ERROR: Exception in callback for signal: cancel: TypeError: this._workspacesViews is undefined
_endTouchGesture@resource:///org/gnome/shell/ui/workspacesView.js:527:25
_emit@resource:///org/gnome/gjs/modules/signals.js:142:27
set enabled@resource:///org/gnome/shell/ui/windowManager.js:478:13
WorkspacesDisplay<@resource:///org/gnome/shell/ui/workspacesView.js:482:9
ViewSelector<@resource:///org/gnome/shell/ui/viewSelector.js:167:35
ControlsManager<@resource:///org/gnome/shell/ui/overviewControls.js:405:29
init@resource:///org/gnome/shell/ui/overview.js:234:26
_initializeUI@resource:///org/gnome/shell/ui/main.js:184:5
start@resource:///org/gnome/shell/ui/main.js:124:5
@<main>:1:31
On startup. Shuffling these two lines prevent this from happening.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/506
The port away from the old Shell.GenericContainer actor turned many JS
classes with a corresponding actor property into Clutter.Actor subclasses.
For compatibility reasons, those properties were kept around for a while.
They were now removed and any code that still uses them should be adjusted.
Facilitate that transition by defining the compatibility property on
Clutter.Actor itself, but log a warning every time it is accessed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/487
- simplify the close button to use blue, lighter blue and darker blue
solid disks for normal, hover and active states
- use a milky, transparent white border for the hover effect of the border
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/461
It may not be immediately obvious that the windows section is a
list of open application windows, as titles like "Downloads" can
easily be confused with an action. Add a section heading to avoid
confusion.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
We currently copy the app icon menu behavior, which puts a separator
between windows from the current workspace and windows from any other
workspace. It is more useful to have the windows section appear as a
clearly marked group, so drop the separator.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/968
Actors themed through CSS should ideally get sizes and positions that
conform to the "pixel grid". A notorious example is the panel that has a
height of 1.86em. On unchanged font settings and hidpi that translates to
55px, which leaves the workarea with "half pixels" that hidpi wayland
applications don't know how to fully cover.
If the requested height is a multiple of the scale factor, the workarea
and maximized applications can then work on full pixels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/91
Work around a known regression from [1] that caused the volume bar in
the OSD window to never be hidden, even if the volume is set to 0. This
happened because the border radius of the barLevel is always drawn
without ensuring that the actual bar is visible.
So simply check if the value to draw is 0, and if it is, don't draw the
border radius of the bar at all. This will still result in incorrect
representation of values that have a width smaller than 2*border-radius,
but at least the bar looks right for a width of 0 now.
[1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/2https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/384
If a window gets destroyed right before it's resize
animation starts the user can get confronted with an undead
zombie clone that doesn't go away.
This commit makes sure said clones get reaped with their
actors.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1166
When determining the biggest icon size that fits the available height,
we first subtract the additional space requirements of icons (spacing,
padding, running indicator etc.) and then divide the result by the
number of icons to get the maximum size available to each icon texture.
In the above, the additional space requirement of each icon is taken
from the first icon (as all icons are assumed to be the same), and
calculated as the difference between the icon button's preferred height
and the currently used icon size.
To make sure that the icon is actually using the dash's current icon
size (even while animating to a new icon size), we enforce its height
during the size request and restore its original height afterwards.
However after some recent changes, that step is causing troubles:
For some reason, the original height may be 0, and when we restore it,
we end up forcing a fixed non-height that bypasses the regular size
request machinery.
While it is unclear where exactly the zero height comes from (maybe
waiting for a valid resource scale?), it is clear that it's best
to avoid forcing a fixed height. So instead of making the icon
texture comply with the assumed icon size, adjust the calculations
to use its current height request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1053
We recently added offsets to world clocks that represent the location's
timezone as UTC offset. However for most users, that representation is
overly technical and less helpful than the difference to their local time.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1157
We currently use the city name for all location except named timezones.
However locations only have a city name if they are of level CITY or
DETACHED, or if they are of level WEATHER_STATION with a parent of level
CITY.
So when libgweather commit d7682676ac9 moved weather station locations from
cities to countries, it broke their names in the world clocks section.
To fix this, stop making assumptions about when we can use the city name
and simply try it first for all locations and fall back to the plain name
if its not available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1150
After the Adwaita refresh, the button shows up oval rather than
circular. To address this, make sure that the "image-button" class
is applied as well by using the dedicated setter function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/482
Compute the source actor workarea and allocation when repositioning and keep it
cached so that we've not to calculating it again in _calculateArrowSide.
Since _calculateArrowSide only is called inside _updateFlip that is always
called just after reposition, we can be sure that the computed values are still
correct.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
Currently all the widgets using BoxPointer and so popup actors are always drawn
at screen origin and then shifted at paint time in the proper position.
This doesn't work when using resource scale, since the widgets need to know
in which monitor they currently are in order to use properly scaled resources.
So, basically revert commit 22c22e0d7 and go back using the actual actor
coordinates for positioning and the actor translation for animating it, as the
relayouting issues of the past seem to be gone now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1008https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/435
Inserting a workspace is implemented by appending a new workspace, then
shifting all windows after the "new" workspace up. This has an unintended
side effect on sticky windows, as changing its workspace will unstick it.
Fix this by excluding sticky windows - there's little point in moving them
anyway, given that they should be on all workspaces (including the original
workspace and the target one).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1151
The monitor index is not something that gnome-shell and
gnome-settings-daemon seem to be agreeing about. Using the connector
string is a much more reliable method of identifying a specific screen
and we are indeed using this already for monitor labling.
So switch over to use the connector rather than the monitor index. If a
user tries to use the old API, then the OSD will simply show up on all
monitors (which is the status quo currently anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/489
This API has been broken for quite some time now as the corresponding
mutter function meta_monitor_manager_get_monitor_for_output was removed.
If anyone tries to use it, we would just run into a backtrace.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/490
Selecting a screen area for a screenshot isn't the same as selecting
items in an icon view, so there's no strong rationale for picking
up the style from GTK. We stopped doing that for other elements like
tile previews long ago, so just use our own style here too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/481
