It appears to be somewhat common for st_widget_style_changed() to be
called when no style-relevant attributes have, in fact, changed. Now that
we cache theme nodes, we're likely to get the same theme node back from
the cache. If we do, we don't need to waste time asking whether its
geometry and painting are equal to itself: we can just note that nothing
really changed and get on with our lives.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If you copy a theme node's paint state into itself, it should be an
inexpensive no-op. What actually happened was that we destroyed the
old paint state, re-initialized to blank, then copied the blank state
back into itself. In the process, we lost (for instance) the textures
for rounded corners.
Until I introduced the texture cache, this never actually happened,
because when st_widget_recompute_style() calls st_widget_get_theme_node(),
we'd always get a fresh theme node. Now, we get a theme node T back
from the cache, notice that paint_equal(T, T) is true, short-circuit
slightly by copying its drawing state into itself, and destroy drawing
state that we still needed.
I'm going to fix this in recompute_style() too, but as a general
principle, self-assignment ought to be harmless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Because we calculate and cache CSS properties once per StThemeNode,
and only a certain set of attributes can affect the CSS properties,
it's advantageous for as many widgets as possible to share a single
StThemeNode. Similarly, if a widget changes state and then changes back
(e.g. gaining and losing the :hover pseudo-class), it should ideally
get its original StThemeNode back again when it returns to the old
state.
Here, I'm using the StThemeContext as the location for a cache.
StThemeNodes are currently never freed: this seems OK for Shell's usage
(a finite number of IDs, classes, pseudo-classes and types).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
In my testing this cuts the longest time to dispatch(), when showing the
calendar menu for the first time, from 604 to 442 milliseconds,
while reducing additional_selector_matches_style() from 32% to 13% of
CPU time used.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
The descriptions for keybindings shared with Metacity are now
duplicated in Mutter, so only use the latter to avoid duplicate
entries in System Settings.
https://bugzilla.gnome.org/show_bug.cgi?id=687672
The screen grabber was a workaround for an extremely slow path in Mesa
when reading back pixel data from the frame buffer. It was using pixel
buffer objects by directly calling into GL to hit a fast blit path in
Intel's driver. This should no longer be necessary with the latest
Mesa because the normal read pixels path now has a fast path to just
memcpy the data. Using PBOs in that case just adds an extra
indirection because the data is read into an intermediate buffer and
then copied back out again.
We want to be able to remove the dependency on linking against libGL
directly from Gnome Shell because that will not work if Cogl is
actually using GLES. Also libGL includes GLX which means gnome-shell
ends up with a hard dependency on Xlib which hinders the goal of
getting Gnome Shell to be a Wayland compositor.
https://bugs.freedesktop.org/show_bug.cgi?id=46631https://bugzilla.gnome.org/show_bug.cgi?id=685915
Due to an oversight, the width of the password entry is currently
determined by the length of the message description. Fix the flags
so that the entry spans the entire width of the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=684810
When updating the dash, we already avoid all animations while the
overview is hidden. However, as we are using Main.queueDeferredWork(),
updates may be deferred up to ~20 seconds while the overview is hidden.
If the overview is entered before a queued update has taken place, it
will be run immediately on map - as the overview is visible by then,
this means animating any outstanding changes.
Work around this by skipping animations during overview transitions as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=686530
If the session mode has no locking support, screenshield had code to
unlock automatically, but it did so by checking the return value of
the constructor, instead of checking if the constructor was actually
callable, so it would get a TypeError before reaching the check.
https://bugzilla.gnome.org/show_bug.cgi?id=687708
At the moment, only the mouse can be used to focus and answer a chat
notification.
This adds a new keybinding (defaults to <Super>+n) to focus and expand
the active notification.
https://bugzilla.gnome.org/show_bug.cgi?id=652082
If I click on "Not listed?" in the login screen, I come to a username
field with two buttons: "Cancel" and "Sign In".
Clicking on "Sign In" doesn't actually sign me in though - it takes me
to the login entry. It would be better to rename "Sign In" to "Next" for
the username stage, therefore.
Gdm emit a signal to ask a question or a secret, but we can not know if
this is the last authentication question, hence we only use "Sign In"
for secret questions which improve the situation a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=687656
When in the overview, if you move the mouse cursor over one of the
application launchers in the dash, all the unrelated windows are dimmed
both both in the window view and in the workspace view.
It helps to easily understand whether or not there are already opened
windows for this application, and where they are. It can also help in
differentiating the windows in the overview (sometimes the thumbnails
aren't precise enough to easily know which thumbnail belongs to which
application).
https://bugzilla.gnome.org/show_bug.cgi?id=657315
This has also the benefit of getting the application even if it can not
be retrieved through AppSystem, which can happen if the runtime WMClass
does not match the one of the desktop file.
This especially looked wrong with the following commits related to the
bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
We simply hide the label when the popup is opened instead of relying
on the popup state when the hover state change.
To do this we replace the flag isMenuUp by a 'menu-state-changed' signal
on the AppWellIcon. This simplifies the dash label visibility handling
code that need additional changes for the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
Initializing this synchronously means that we will possibly wait for the
process to be auto-activated and answering to our call.
If the process is already running it also might not answer immediately
our request, as it might be doing sync I/O.
The right thing to do is to initialize the proxy asynchronously; there
are try/catch blocks in place for when the object is not available, or
not properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
This is called in the main thread, which we should never block for
synchronous I/O.
Since the operation we're wrapping is async already, just use
g_file_query_info_async() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
Remote search providers install an auxiliary keyfile to specify
static information, such as the object path/bus name needed to activate
the binary. Such keyfiles also specify the application the providers
pushes results for; currently, we support two formats for application
information
- two fields, "Title" and "Icon" that specify a (translatable) title and
an icon name for display
- one field "DesktopId" that specifies the desktop file name of the
application backing the provider, which obsoletes the previous
Title/Icon syntax
Since all providers in GNOME use DesktopId now, and we need to ensure a
remote search providers is always backed by an application for future
development, this commit drops the support for the older syntax.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
Switch from a ClutterDragAction to a ClutterGestureAction, that gives
us the velocity of mouse motion at each step, and use it to compute the
animation time for completing the hide gesture.
https://bugzilla.gnome.org/show_bug.cgi?id=682537
The background is the same as the normal desktop, so we blur and
desaturate it to clearly show that it's not the normal system state.
To do so, we don't use standard ClutterEffects, to avoid the FBO
indirection. Instead, we take advantage of MetaBackgroundActor support
for GLSL code and paint the shaded background texture directly.
https://bugzilla.gnome.org/show_bug.cgi?id=682536
In some deployments showing a user list at the login
screen is undesirable.
GDM's fallback login screen has a configuration key:
org.gnome.login-screen disable-user-list false
that causes the user-list to get hidden.
This commit adds similar functionality to the normal,
shell-based login screen.
Based on a series of patches by Marius Rieder.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
Right now when a user clicks "Not Listed?" they end up
seeing a session list that gets reset after they enter their
username.
This commit hides the session list until the username has
been entered.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
For the "Not Listed?" case we will need to be able
to identify when the user has entered their username.
Once we have a way of tracking when the username is
entered, we can then defer showing the session list
too early, before the user can reliably pick a
session.
This username tracking will also be important for
implementing a disable-user-list configuration key.
If the config key gets toggled off at runtime, we'll
need to know if we're at a disruptive part of
the authentication process or not, so we know whether
we can can expose the user list right away, or wait
until the authentication conversation finishes.
Right now, we pass null in for an initial username,
and let the PAM machinery ask the user, which means we
have no good way of knowing when the username is entered.
This commit changes the "Not Listed?" code to ask the
user their username up front, before starting the PAM
conversation in much the same way we do if the user
picks a user from the user list.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
After some changes, the tooltip label at the dash is not available
until it is visually shown. As this is not anymore a reliable
source of accessible name, we just set the accessible name
with the string used on that label.
https://bugzilla.gnome.org/show_bug.cgi?id=686583
