It apparently uses no ClutterTexture specifics, and instead
only tries to match what StTextureCache used to return.
Since StTextureCache now returns ClutterActor, also use a
ClutterActor on ShellApp.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/373
_st_create_shadow_pipeline_from_actor creates shadow pipelines
from actors. This function special-cases ClutterTexture as a
small performance improvement, since we can have access to the
CoglTexture easily with it. However, recent commits removed all
usage of ClutterTexture from GNOME Shell, rendering this optimization
useless. Instead, actors now may have a ClutterImage set as
their content, that can be used instead.
Replace the check for ClutterTexture with a check for ClutterImage,
and use the texture of the image when it is available.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/371
The Magnifier class uses a small subtree of actors to track the
current cursor's position and sprite. Specifically, it uses the
deprecated ClutterTexture to paint the cursor sprites.
Add a new, very simple ClutterContent implementation to track the
cursor sprite, and replace the ClutterTexture by a ClutterActor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/371
This drops usage of Gtk/X11, replacing it with code that is dependent
of the Clutter backend in use. Another positive side effect is that
the keymap state will now be correct on wayland, since there were no
guarantees that X11 key state would reflect the current reality.
https://bugzilla.gnome.org/show_bug.cgi?id=762881
This is an expensive operation that is best avoided in the main loop. Given
the call doesn't care much about returning error or status, it can just
be made async within.
Every operation on a given file will be destructive wrt previous
operations on the same file, so we just cancel any pending operation on
it before batching the current one.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/815
The last patch in the series, this one adapts StShadowHelper
to received a CoglFramebuffer. This is where we first touch
JavaScript with Cogl types, and as such, it depends on the
latest Mutter. Earlier versions of Mutter didn't have its
Mutter-Clutter GIR to generate types for various Cogl types.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
Same case of the previous patch; _st_paint_shadow_with_opacity()
uses cogl_get_draw_framebuffer(), and this patch makes it receive
a CoglFramebuffer as a parameter instead.
The cautious reader might notice that this commit apparently goes
against the long-term goal, for it introduces more instances of
cogl_get_draw_framebuffer(). This is not wrong, but these introduced
ones will be removed later on, when ClutterActor.paint() receives
a CoglFramebuffer as a parameter instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
This is in preparation for a future where only explicit frambuffer
APIs are available, i.e., cogl_get_draw_framebuffer() does not
exist.
There is absolutely no functional changes in this patch (nor the
following ones in this series), only rearrangements so that various
functions receive a CoglFramebuffer instead of using the draw
framebuffer.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
This was called here just to end up emitting ::installed-changed,
which would trigger other g_app_info_get_all() calls. Cache it here
so it may be reused later on.
Handling those events is neccessary if a touch event that pressed down a
button turns out to be a gesture. In this case the button should be
released without emitting the clicked signal.
After loading the GdkPixbuf, StTextureCache unconditionally
creates a ClutterImage and, if it's not in the cache, add
it to the cache. That's a waste of resources when the image
is already committed to the texture cache.
Fix that by reusing the ClutterImage of the cache if it is
already there; otherwise, create a new ClutterImage as we
were previously doing.
ClutterTexture is a deprecated class that is simultaneously
an actor, and the content of the actor. Clutter's new model
is to separate painting (via ClutterContent) from actors.
Currently, StTextureCache relies on ClutterTexture to store
the loaded textures. This not only does not match the latest
practices of Clutter, but also generates various compile-time
warnings.
Port StTextureCache to store ClutterImages instead of storing
ClutterTextures. ClutterImage exposes the internal CoglTexture,
so no helpers are needed to match the current StTextureCache
API. Aspect ratio was dropped, but from my testing, it doesn't
change anything.
All callers have been updated to use MetaSoundPlayer. This drops direct
usage of libcanberra-gtk, and the X11 connection indirectly. One thing
worth noting is that we pass less metadata (eg. event x/y that might be
used for surrounding effects). This was all largely unused, so the
MetaSoundPlayer was made simpler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/327
When computing the effective border color, we operate on colors with
premultiplied alpha to simplify the calculations, then unpremultiply
the result. However we miss a bounds check in the last check, so any
color component can overflow the allowed maximum of 0xff and shift the
result in unexpected ways.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/305
If the actor is not on the stage yet (i.e. does not have a theme
node), but has a paint state cached, we currently fail to invalidate
it, which will lead to the actor painting with old contents once it
gets onto the stage.
This commit fixes the issue by changing our invalidation strategy;
previously we were looking at the widget's own theme node to determine
if it should be invalidated or not.
Now we look at the theme nodes of our cached paint states. When the
widget is mapped on stage, those are the same as the widget's own
theme node, but when the widget is not on the stage, we'll still be
able to invalidate them.
As part of this, we move the invalidation API to StThemeNodePaintState,
which is a more natural place for our use case.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/314
In X11, pointer emulated touch events are replicated with normal PRESS, RELEASE
pair events which are generated by the server. Thus for a single tap we get:
- TOUCH_BEGIN -> TOUCH_END, PRESS -> RELEASE
This will cause st-button to send two "clicked" signals, instead of just one,
breaking extensions (like dash-to-dock) that show buttons in the main stage
which will be checked two times or that will receive the same signal two times.
Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
cogl_texture_new() is used in a few places in GNOME Shell, but
it's a deprecated Cogl function. The replacement is the less
verbose cogl_texture_2d_new_with_size(), that is very much a
straightforward replacement.
Remove the few places where this function is used, replacing
it by the CoglTexture2d counterpart.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/287
StTextureCache installs file monitors that invalidate caches when
contents of the underlying file change.
At the moment, the cache uses the Gio.FileMonitorEvent.CHANGED event
type to make that determination.
However, that is suboptimal for at least two reasons:
- while a file is being written to disk, many CHANGED events will be
emitted in sequence. That will cause needless cache invalidations,
and we will risk loading the file before it's fully loaded.
- if an existing file is replaced, e.g. with g_file_replace(), we may
not get a CHANGED event but a CREATED one instead, so the cache ends
up never getting invalidated.
The good news is that in both of those cases GFileMonitor will send a
CHANGES_DONE_HINT event after changes have settled, or after the file
is replaced.
This commit fixes both cases by switching from the CHANGED event to
CHANGES_DONE_HINT to determine that a file has in fact changed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/286
If the initialization fails for some reason, for example by
running 'gnome-shell --replace', we should not crash because
of an attempt of unregistering an unregistered agent handle.
Fix that by checking if the handle is not NULL before calling
the unregistering routines.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/66
According to Clutter documentation, "[…] actors implementing the
ClutterContainer interface should override the default implementation
of the class handler of this signal and call clutter_actor_destroy()
on their children."
StBin was doing that in GObject:dispose() instead. Move the child
destruction to a new ClutterActor:destroy() vfunc override.
StBoxLayout implements StScrollable, which, semantically, means that
the StBoxLayout size may not match the minimum size reported by the
layout manager. In this specific case, the layout manager by is a
ClutterBoxLayout by default. For example:
+--------------+
| Viewport |
+------+--------------+-----------------+
| | | |
| | | Content |
| | | |
+------+--------------+-----------------+
| |
+--------------+
So, assuming that:
- ContentSize = the minimum size of the content;
- ViewportSize = the allocated size of the viewport;
When allocating StBoxLayout, it must assume ViewportSize, but must
pass ContentSize to the layout manager. That way, the children of
StBoxLayout are correctly placed within it, even if it's bigger than
ViewportSize.
And here's the problem: right now, StBoxLayout assumes ViewportSize
AND also passes it to layout manager. Commit 77c4c6b6d specifically
exposed this bug by relying entirely on StBoxLayout to arrange the
app and window icons.
Fix that by using ViewportSize to allocate StBoxLayout itself, but
passing ContentSize to the layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
gjs now relies entirely on introspection data to determine parent
types and implemented interfaces, so in order to have all methods
and properties resolve correctly, we must include the corresponding
GIRs of all types used.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/574
There's no relation between a window being hidden from overview/taskbars
and a window not being closable - currently we effectively disable the
fallback quit action for any application with open transients, which
simply doesn't make sense.
Instead, only exclude windows for which the close action has been
explicitly disabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/217
Using a single resource file for all JS sources saves a couple of
build system instructions, but has some serious downsides:
- bundling the entire shell code with the tools blows
up their size unnecessarily
- the tools are rebuilt unnecessarily for any shell
code change
Autotools was painful enough to let this slip, but with meson we
don't have any excuses - using the actual dependencies speeds up
the build a tiny bit and reduces the tools' sizes from over 2M
to about 50k.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/192
Simply reusing the same dependencies as gnome-shell itself not only
means that we link tons of stuff unnecessarily, but also that we
have to do the whole mutter rpath dance for nothing. Just use the
dependencies those executables actually need for a nice cleanup.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/192
We need this in the main gnome-shell executable in order to locate
the private Shell and St typelibs, but those aren't useful or even
usable in the extension-prefs/portal helper tools.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/192
GSettings now recognizes per-desktop overrides that can be used
to change schemas' default values for a particular desktop. This
is not entirely unlike our existing custom override mechanism in
mutter, except that it is not limited to keys in org.gnome.mutter,
and it doesn't require a separate schema - the latter means that
we (and gnome-teak-tool) no longer have to figure out the correct
schema for the current login session and just use the original one.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
Add a debug command (to be executed manually via Alt+F2) to check
that all of gnome-shell's file descriptors have the CLOEXEC flag set.
This is important so that internal file descriptors do not get passed
to apps when they are launched.
It prints a warning message for every fd that does not have the flag set.
fdwalk() is used from the standard library if available (it is not
available in glibc), otherwise we use the same implementation as glib
has internally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen. This check is somewhat irrelevant because we are only forking
to immediately exec(), which will discard the whole virtual address
space anyway.
This issue can be avoided by using a new optimized gspawn codepath in
the latest glib development version, which uses posix_spawn() internally.
For the optimized codepath to be used, we must not pass a child_setup
function, so the the file descriptor management is reimplemented here
using new glib API to pass fds to the child process. The old API will
continue to be used on older glib versions.
We must also change the spawn flags for this code path to be hit.
I checked that gnome-shell's open file descriptors are all CLOEXEC
so using G_SPAWN_LEAVE_DESCRIPTORS_OPEN should be safe.
This will result in more resilient app launching when memory is low,
since the optimized spawn path avoids cloning the virtual address
space of the parent process (gnome-shell) and avoids the irrelevant
memory overcommit check.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
While can_open_new_window() uses some elaborate heuristics to predict
whether an application can open multiple windows, open_new_window()
will always simply relaunch the application. This is often the best
we can do, but when an application provides a "new-window" action in
its .desktop file or on the bus, it is much more likely to work as
expected than blindly activating the app and hoping for a particular
behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=756844
Graphical applications like GIMP or GIMP allow picking colors from
any location on-screen. In order to keep supporting this feature
on wayland and in sandboxed apps, we will expose an appropriate
method in the Screenshot interface, so first add a corresponding
method to ShellScreenshot.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/286
A custom callback type is more convenient, but only as long as no
other callback type is required. We are about to add functionality
that does not return the filename to a screenshot saved on disk, so
prepare for that by moving to GIO's generic async callback pattern.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/286
So that we can be started by systemd --user, instead of gnome-session.
There are three units:
- gnome-shell.service: Start gnome-shell itself.
- gnome-shell-x11.target, gnome-shell-wayland.target: Sync points for
units that need to care if x11 or wayland is in use.
gnome-settings-daemon will use these, for example.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/138
