First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
The current code only sets up / updates transitions when the new
node's transition-duration is non-zero. It should cancel an
existing transition if the duration is 0.
It is sometimes desirable to fade smoothly between two styles
instead of changing it abruptly.
Add transitions controlled by the transition-duration CSS property.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
StThemeNodes may have properties - namely shadows - which paint
outside an actor's allocation. This is not a problem unless drawing
is redirected to an offscreen buffer, in which case the actually
painted size is needed in advance when setting up the buffer.
Add a convenience method to calculate an allocation large enough to
paint the node.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
Add st_theme_node_equal() - two nodes are considered equal iff they
refer to identical elements, so e.g. .example and .example:hover are
not equal, even if no .example:hover rule exists in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
Previously we were trying to match up remote windows with local
.desktop files, which is definitely wrong. This patch simply
falls back to the app-from-window case for this; better handling
would need design.
https://bugzilla.gnome.org/show_bug.cgi?id=620855
Separate out the main app view into different sections based on the categories
in the desktop file. The configuration is done via gmenu and the desktop menu
specification, we set XDG_MENU_PREFIX="gs-" on startup, so that gmenu reads
gs-applications.menu, which we install.
There is no support for "submenus" - only the menus directly under
Applications will be displayed as categories.
https://bugzilla.gnome.org/show_bug.cgi?id=614131
Currently we only relayout when the screen size changes, this gets
the cases where a monitor gets added/removed but not when the primary
monitor changes.
We need to relayout on all monitor layout changes.
Remove ShellGlobal::screen-size-changed signal as it is no longer used, Gdk is
used to track changes now.
A ShellGlobal::gdk-screen property is added for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=620377
When hovering over the entry's ClutterText, the entry itself
currently receives a leave event and updates the hover state.
Apply the same logic as StWidget itself to treat children as
part of the entry.
https://bugzilla.gnome.org/show_bug.cgi?id=620381
Add an event when we receive an event on buffer swap completion; we'll
only get this if Clutter is using the INTEL_swap_event GLX extension,
but it's useful to see the actual timing of video frames.
The recorded event includes the actual timestamp of the swap, since
we are given that in the GLX event - on my system it tends to be
consistently 80-100us before we log the event, but if something was
going wrong in event handling (too much synchronous work), then that
could could show up as a longer delay.
https://bugzilla.gnome.org/show_bug.cgi?id=619516
Currently shadows disregard the overall opacity, so e.g. setting
an ancestor's opacity does not effect the shadow. Fix this by
deferring the setting of the shadow's color until it is painted.
Also move duplicated drawing code from st_theme_node_paint() into
its own function.
https://bugzilla.gnome.org/show_bug.cgi?id=619083
The preference dialog for the panel clock does not set its gettext
domain, so it's not translated even if though translations are
already available.
Fix by setting the domain in the GtkBuilder file and binding the
domain to the locale directory.
https://bugzilla.gnome.org/show_bug.cgi?id=618873
Currently the size of an StGroup depends exclusively on the group's
children - it should be possible to override this behaviour with
fixed values in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=613907
Update the GNOME Shell version to 2.31.2, and make corresponding
updates to dependencies:
clutter => 1.2.8
mutter => 2.31.2
gobject-introspection => 0.6.11
gjs => 0.7
Typo: 10000000 instead of 1000000 for a million. Also, use
G_INT64_CONSTANT instead of LL for a 64-bit constant, to avoid
extraneous 128-bit arithmetic on 64-bit machines.
Add a command line option to upload the generated performance report
to a web service. The options for the upload (url, system name, secret
key) are read from ~/.config/gnome-shell/perf.ini.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Switch from having separate METRICS and METRIC_DESCRIPTIONS objects
in a perf module to a single METRICS array. This is done so the
perf module can define the units for each metric.
In addition to improving the output in the web interface, the purpose
of having units is to give some clue about how to pick from multiple
values from different runs. In particular, with the assumption that
"noise" on the system will increase run times, for time values we want
to pick the smallest values, while for "rate" values, we want to pick
the largest value.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add --perf-output=<filename> option to gnome-shell that combines
the reports written for each run by the C/Javascript code into
a complete report.
If this option is not specified, a brief human-readable summary
is printed to stdout instead.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
When SHELL_PERF_OUTPUT is set, instead of just dumping out the metrics, dump
a more complete report with:
- Event descriptions
- Metric descriptions and value
- Event log
Helper functions shell_perf_log_dump_events() and shell_perf_log_dump_log()
are added to ShellPerfLog to support this. The gnome-shell wrapper is adapted
to deal with the changed report format.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add a helper function to write a string as UTF-8 to a GOutputStream.
The signature of GOutputStream:
gboolean g_output_stream_write_all (GOutputStream *stream,
const void *buffer,
gsize count,
gsize *bytes_written,
GCancellable *cancellable,
GError **error);
Can't currently be handled by GJS.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add gnome-shell options:
--perf-iters=ITERS"
Numbers of iterations of performance module to run
--perf-warmup
Run a dry run before performance tests
Make a successful run of a performance test return 0 not non-zero,
and handle the difference between that and a 0-exit in normal
usage (meaning replaced) in the wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Move the code that starts gnome-shell and waits for it to exit
to a function in preparation for running it multiple times when
doing iterations of a performance test.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add some basic statistics for allocated memory based on mallinfo(),
and use that to define two metrics:
usedAfterOverview: bytes used after the overview is shown once
leakedAfterOverview: additional bytes used when the overview is
shown a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
Add a facility for defining and recording numeric statistics
as performance events
shell_perf_log_define_statistic()
Define a statistic and the corresponding event type
shell_perf_log_update_statistic_[ix]() -
Update the stored statistic value
shell_perf_log_add_statistics_callback()
Add a function called before collecting statistics
shell_perf_collect_statistics()
Update statistics and record events for them
In addition to the explicit collection, statistics are
recorded at a periodic interval (currently 5s)
https://bugzilla.gnome.org/show_bug.cgi?id=618189
We want to be able to summarize the behavior of the shell's
performance in a series of "metrics", like the latency between
clicking on the Activities button and seeing a response.
This patch adds the ability to create a script under perf/
in a special format that automates a series of actions in the
shell, writing events to the performance log, then collects
statistics as the log as replayed and turns them into a set
of metrics.
The script is then executed by running as gnome-shell
--perf=<script>.
The 'core' script which is added here will be the primary
performance measurement script that we use for shell performance
regression testing; right now it has a couple of placeholder
metrics.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
ShellPerfLog provides a way for different parts of the code to
record information for subsequent analysis and interactive
exploration. Events exist of a timestamp, an event ID, and
arguments to the event.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
To support scheduling performance-measurement scripts that want to run
a number of actions in series, add shell_global_run_at_leisure() to run
a callback when all work is finished.
The initial implementation of this is not that accurate: we track
business in Tweener.js via new shell_global_begin_work(),
shell_global_end_work() functions, and we also handle the case
where the main loop is continually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=618189
The API docs for ShellApp claimed it sorted by the last time the
user interacted with the app, but if one closed a window, then
we would fall back to comparing against a possibly much older
timestamp from another window. Fix this by just keeping a
user time per app.
Also clean up the comparison function to explicitly check the state
instead of deferring to the window list.
https://bugzilla.gnome.org/show_bug.cgi?id=618378
The ShellGlobal initialization performs several actions like connecting
to the X server, ensuring directories exist, etc., that are problematic
because we were creating the object even when running the binary for
introspection scanning. During compilation we may not even have X11
available in e.g. autobuilder type environments, and it's just a
bad idea to connect even if we do.
Avoid this by deferring creation of the ShellGlobal object
until the plugin is actually started.
Now that we're initializing things later, remove the connection to
screen changes, and initialize cached ShellGlobal state at the point
when the plugin is set. The root pixmap actor is now sized initially
on creation too. Instead of relying on screen-size-changed being
emitted on startup, explicitly invoke _relayout().
https://bugzilla.gnome.org/show_bug.cgi?id=618371
I have no idea why there existed code that if we saw e.g. min-width
without a width, we assigned min-width to ->width, thus effectively
treating it as a maximum.
Just delete that bit.
https://bugzilla.gnome.org/show_bug.cgi?id=618482
Starting with gtk-2.20.0 there is a gdk_screen_get_primary_monitor,
which supports querying the primary monitor from xrandr.
But due to a sorting bug and lack of heuristics in the fallback path,
it isn't really useable.
Those bugs are fixed in gtk-2.20.1, so use it when building with
gtk-2.20.1+.
https://bugzilla.gnome.org/show_bug.cgi?id=608647
Passing an explicit width in the wfh case or a height in the hfw case
messes up the request caching, and confuses actors that assume they
won't be called with an explicit width/height unless they're being
allocated along the other axis.
https://bugzilla.gnome.org/show_bug.cgi?id=618295
Adds the ability to create one or more zoom regions that show magnified or
enhanced views of the desktop. The magnifier provides options for:
* magnification factor,
* four mouse tracking modes common to screen magnifiers,
* positioning the magnified view in one of four screen location, or full screen,
* crosshairs to accentuate the position of the mouse,
* user preferences persistence via GConf (schemas in
.../data/gnome-shell.schemas).
* a DBus API to allow other processes to drive the magnifier as a service.
https://bugzilla.gnome.org/show_bug.cgi?id=595507
