In the mockups the slider does not have an uniform color but uses
one color (shade of blue) to indicate the current value and one
to indicate "the rest" (shade of grey).
So adjust the slider to look like that to be closer to the look
in the mockups and thus to the design.
https://bugzilla.gnome.org/show_bug.cgi?id=644600
clutter_init() fails under normal circumstances like
being unable to open a display connection, so it shouldn't
be handled with g_error() producing a core dump.
Clutter consistently produces an error message when
clutter_init() fails, so we don't need to print out any
error message.
https://bugzilla.gnome.org/show_bug.cgi?id=643910
GJS complains when a NaN is passed in place of an integer, and
parseInt returns that from non numeric string. Pass a sentinel
that cancels the operation in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=642978
The number instructions in a shader is limited to 64 on r300 hardware,
the fade shader in StScrollViewFade was ending up using 97 instructions
which is way over the limit.
So refactor the shader to use less instructions by precomputing as many
values as possible outside of the conditionals. The resulting shader
ends up using 34 instructions which is well within the hardware limits.
https://bugzilla.gnome.org/show_bug.cgi?id=644589
GThemedIcon expects the first name to be the most specific, and
will thus prefer it to later ones. We thus need to order the names
from the longer to the shorter.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
Around 2.91.90, gnome-session-save was renamed to gnome-session-quit.
This commit restores compatibility with the older gnome-session, for
those testing under GNOME 2.32 or below, by calling the DBus methods
directly.
https://bugzilla.gnome.org/show_bug.cgi?id=644591
Add the idea of an 'id' for a tab, and add a public switchTab method
so you can switch to 'applications' or 'windows'. This will be useful
for performance tests that test tab switching performance.
https://bugzilla.gnome.org/show_bug.cgi?id=644266
Add metrics:
overviewFps5Windows
overviewFps10Windows
overviewFps5Maximzed
overviewFps10Maximized
overviewFps5Alpha
overviewFps10Alpha
To have more numbers to show how performance varies with different
numbers of windows and different types of windows (maximized,
with an alpha channel.)
https://bugzilla.gnome.org/show_bug.cgi?id=644265
* Run gnome-shell-perf-helper during performance tests
* Use MUTTER_WM_CLASS_FILTER to omit all other windows
* Add new Scripting methods: createTestWindow,
waitTestWindows, destroyTestWindows
* Create a single 640x480 test window for testing overview
animation performance.
https://bugzilla.gnome.org/show_bug.cgi?id=644265
We need to connect to the NameOwnerChanged signal before we execute the
DConf binary. Refactor things so that we connect to the signal when
we first get the bus object. Split the code for waiting for a D-Bus
name into a wait_for_dbus_name() function for latter reuse.
https://bugzilla.gnome.org/show_bug.cgi?id=644265
Don't enter the overview at startup, or when we we remove the
last window on the first workspace, but only when we remove a
workspace and there are windows on the other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=644541
When new messages come in we want to scroll down so that the user
sees the incoming messages. The current implementation does not work
because it relies on a synchronous allocation hack which does not work
for unmapped notifications.
Fix that by connecting to adjustment::changed and scroll whenever the
adjustment changes which equals "new messages", "new timestamp" or
"presense change", but don't interference with the user's scroll actions
i.e when the user scrolls back to read something don't scroll to the bottom.
https://bugzilla.gnome.org/show_bug.cgi?id=614977
Remove the hack from Notification.scrollTo because it is unreliable,
the caller should make sure to call scrollTo when it will actually
have the desired effect.
https://bugzilla.gnome.org/show_bug.cgi?id=614977
If we're dragging a window around and we need to reposition the windows,
due to e.g. the sliding in of the thumbnails or some other reason, then we
need to consider the original position of the dragged window, rather than
the currend drag position. Otherwise we will unnecessarily rearrange the
other windows for instance on snap-back if you moved the dragged window
past some other window.
https://bugzilla.gnome.org/show_bug.cgi?id=643786
