There have been multiple notifications ever since we had a notification stack
per source, so the idea of one notification being on screen at a time has long
been dead.
https://bugzilla.gnome.org/show_bug.cgi?id=661615
We seem to have a lot of code that does something along the lines of:
if (condition)
actor.show();
else
actor.hide();
ClutterActor already has such a thing for exactly this purpose: the 'visible'
property. Use it instead of the mess above.
https://bugzilla.gnome.org/show_bug.cgi?id=672272
We hide the content around displaying new search results to prevent
flickering, unfortunately, one side effect of hiding an actor is
losing key focus if it currently is on the that actor or any
child. This could happen in the case of async results showing up after
the user had moved focus to the search results.
This patch works around that issue by saving the key focus and
resetting it back after displaying the new async results.
https://bugzilla.gnome.org/show_bug.cgi?id=675078
We already have one too many logging systems. Remove the errors tab
and make global.log/global.logError point to window.log/window.logError
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=675104
Lots of things here were unused. First, we don't need to calculate
the js_dir when not running from the source tree, which makes the
branch mostly empty, meaning we can merge the two branches.
This allows us running uninstalled. While we're at it, though, remove
JHBUILD_TYPELIBDIR. jhbuild shell should add its own stuff to GI_TYPELIB_PATH,
and we don't want to half reimplement jhbuild. The wrapper script should be
solely for the case of running from the source directory, and not care about
jhbuild at all.
If start_shell throws an exception for whatever reason, the finally
handler will run before shell has been set, leading to a "referencing
an undefined local variable" error.
If a request isn't found in shell_network_agent_set_password() or
shell_network_agent_respond(), then g_return_if_fail() rather than
crashing. OTOH, if a request is not found in
shell_network_agent_cancel_get_secrets(), then just ignore it
silently, since that could legitimately happen.
https://bugzilla.gnome.org/show_bug.cgi?id=674961
Right now, we are hard-depending on the presence of Evolution by
using its settings schemas. This is likely to be unpopular, and
also causes instability if someone happens not to have Evolution
installed, so install a schema that has the same data path as
the Evolution schema, but a different name and install that
for the keys we need.
To avoid a string-freeze break, we rely on the translations in
Evolution - if Evolution isn't installed, the key descriptions
will be untranslated in dconf-editor.
https://bugzilla.gnome.org/show_bug.cgi?id=674424
This swaps a use of GLfloat for a regular float. Cogl might stop
including a GL header in its public headers soon so this would fix a
compilation error.
https://bugzilla.gnome.org/show_bug.cgi?id=672711
If run under jhbuild, gnome-shell is in PATH, so trying to restore
is just running it again, likely failing in the same way (with the
additional problem of detaching the shell from the terminal). Also,
this is using deprecated GConf keys, and deprecated pygobject
bindings.
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
