We currently assume that every location has an associated timezone.
While this is sound in the real world, in practise it depends on
whether or not libgweather can find a corresponding timezone DB
entry.
This used to be a fringe case, but has become more likely when commit
https://gitlab.gnome.org/GNOME/libgweather/commit/d7682676ac9 moved
weather stations from cities to countries - the station itself is un-
likely to have a timezone entry, and the country may be part of more
than a single timezone.
It would be good for libgweather to return a timezone for those
locations again, but we should defend against the case anyway.
We cannot tell what time it is at a particular location without
knowing the timezone, so simply filter them out.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1062
The parameters that may affect the icon on ::style-changed are more size
related than visual (we listen to icon theme changes for the latter). It
makes sense to just update the icon if the size came out different.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
With a high enough amount of actors, there may be enough theme nodes and
signal connections on StTheme::custom-stylesheets-changed that
g_signal_handlers_disconnect_by*() on dispose becomes expensive, this may
become a surprisingly hot spot in StWidget::style-changed.
Keep the handler ID around and use g_signal_handler_disconnect() to avoid
linear lookups for the matching func/data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
The top bar handles allocating all its children itself, so there's
little value in chaining up to st_widget_allocate() and get the
default layout manager allocating all children again (and possibly
differently).
If this happens, we end up with an infinite allocation cycle with
corresponding performance penalty. Fix this by just doing and what
Shell.GenericContainer did before commit 286ffbe2b6 replaced it,
and not chain up to StWidget.
Thanks to Robert Mader for debugging the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1054
On one hand, we were using a path instead of an URI on
rsvg_handle_set_base_uri(). This broke at some point in librsvg
(presumably for the best, handling paths there sounds non-standard)
leaving a blank svg (As the base image wouldn't be accessed).
On the other hand, we use this with the deprecated rsvg_handle_write()
which we should drift away from.
Using rsvg_handle_new_from_stream_sync() neatly solves both. We use
newer API based on input streams and GFiles, and it internally does
the right thing, bringing the pad OSD back to life.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1220
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Classes that are sub-classes of GObject don't use a constructor per se, so we
can't check for new.target (as this is undefined) in _init.
Then compare the current constructor name instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/503
Unlike regular keys that generate key events from a virtual device,
emoji keys rely on the input method to insert the character. However
as the compositor cannot inject IM events into ibus, this only works
in the shell's own entries on X11.
We shouldn't expose mostly broken functionality to the user, so limit
the feature to the wayland session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1172
Depending on how gitlab's CI checks out gnome-shell, the shell branch
may not have a local reference like "gnome-3-32", but only a remote
one like "remotes/origin/gnome-3-32".
Consider that case as well when looking for a corresponding mutter branch.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/511
If we don't find a branch that matches the branch used in the merge
request, we currently fall back to the non-merge-request matching,
i.e. first try the current shell branch, then fall back to master.
This should work for commits to upstream branches, but not for merge
requests to a stable branch. For those, the target branch name is
a better fallback.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/509
Move the signal handlers for changed settings to be connected after the
creation of the menu items to make sure a reference to the item is set.
While it also worked fine before, this solution certainly looks cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/512
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
