The jhbuild wrapper is expected to be run through jhbuild run, or
in the uninstalled case inside a jhbuild shell, so there should
be no need to set XDG_DATA_DIRS and friends.
dconf-daemon is available since 2.32, so there is no need to
start it manually (and in fact, it should not be running normally).
Similarly, notify-osd and notification-daemon should not be
dbus activated, but rather autostarted by gnome-session, and
therefore not running in a gnome-shell session.
Introduce a new gnome-shell-perf-tool, which can be used instead
of the old gnome-shell-jhbuild wrapper to gather data about gnome-shell
performance and submit to shell-perf.gnome.org. This runs the
shell with no extra setup beyond the WM_CLASS filter, so it can
be used for a jhbuild setup or for an installed shell.
Currently the scroll event code only handles scroll events if the
adjustment's value is within the "lower" and "upper" limits. The
likely intent was to pass events to a parent scroll view when
reaching the bounds (uh, nested scroll views!), but apparently
we never made use of this, as the upper bound is actually wrong
(an adjustment's maximum value is upper - page_size, not upper).
Just handle all scroll events unconditionally and rely on the
bound checks in StAdjustment.
https://bugzilla.gnome.org/show_bug.cgi?id=672413
The keybinding to toggle the screen recorder was implemented as a
signal on MetaScreen, as keybindings could only be defined in mutter
core. As this is no longer the case, we can move the binding into the
shell where it belongs.
https://bugzilla.gnome.org/show_bug.cgi?id=674377
We now require Mutter 3.4.1 for the API change to
meta_display_add_keybinding(). (This is a run-time requirement, not
a build-time requirement, since the usage is from Javascript.)
When receiving another message or responding in a new expanded chat
notification that has no prior chat history, the notification moved down
below the edge of the screen instead of expanding up, making part of it
invisible. Avoid this by making sure the notification's position is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=661944
Evolution now stores its selected calendars and tasks in GSettings, not
in GConf. If we don't look at the new location, then we'll not pick up
newly added and enabled calendars, making the calendar effectively not
work for new installs.
https://bugzilla.gnome.org/show_bug.cgi?id=673610
If evolution-data-server needs to prompt for a password, it will try
to pop up a GTK+ dialog. When GTK+ is not initialized, the result is
a crash. So, initialize GTK+ and run a main loop.
See https://bugzilla.redhat.com/show_bug.cgi?id=809681
The result is ugly since we have a Gnome-shell-calendar-server fallback
application, but I don't think it's worth installing a desktop file
and having a string break, since this is pretty uncommon (only for
manually added calendars without the password stored in gnome-keyring),
and apparently this is being rewritten for 3.5 to have the dialogs come
the e-d-s daemon rather than from the individual application.
https://bugzilla.gnome.org/show_bug.cgi?id=673608
A BindConstraint on the size of uiGroup forces full redraws of the scene.
Instead, implement and use get_preferred_width and get_preferred_height.
https://bugzilla.gnome.org/show_bug.cgi?id=670636
Commit 26580f8f reintroduced an optimization on style changes to avoid
creating icons unconditionally. As this breaks icon theme changes (for
instance when toggling "High Contrast" in the universal access menu),
remove it again.
https://bugzilla.gnome.org/show_bug.cgi?id=672941
gnome-shell-extension-prefs uses format(), but can't pull in Shell
(which is a dependency for the module), since that in turn would pull in
Meta. Fix this by moving the introspected int format function to ShellJS
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=673106
nm_active_connection_get_devices() has a (questionable) special case
for the no devices case (which happens if the DBus object is
destroyed because NM went down): it returns null instead of an empty
array. Handle that instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=673043
Icon theme change signals aren't noticed immediately, they're usually
noticed when trying to load an icon. Since icon theme changes cause a
style change, and most icon widgets try to re-load their texture during
a style change, this means that we get a stack like this:
st_texture_cache_load_icon
gtk_icon_theme_lookup_icon
gtk_icon_theme_changed
st_widget_style_changed
st_texture_cache_load_icon
Rather than making every place that uses StTextureCache re-entrant,
punt the notifying of icon theme changes to an idle handler instead.
https://bugzilla.gnome.org/show_bug.cgi?id=673512
