Util.ensureActorVisibleInScrollView takes care of the potential scroll view fade
effect in order to compute the scroll offset, reading the ScrollViewFade's
`vfade-offset` property. This was correctly working until gnome 3.30 cycle.
However such property isn't defined now because since gjs 1.54, it can only
fetch introspected properties and St.ScrollViewFade was considered a private API
not exposed by gir.
Fix this by also introspecting st-scroll-view-fade sources.
Not being considered private anymore, install the header.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1061
Updating the :first/:last-child pseudo classes can result in a lot
of unnecessary style changes when bulk-adding children to a container,
as every child ends up as the new last child.
Address this by deferring the style change to an idle, so we only do
the work once for the actual first and last child.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/529
Images are loaded either with a supplied fixed size, or using the "native"
dimensions of the file. When creating a content image from the loaded data,
we currently simply apply this directly to the preferred size.
This works usually fine: GdkPixbuf will always keep the aspect ratio, so
if only one dimension is provided, the other will be adjusted accordingly:
Loading a 200x200 image with a requested size of (100, -1) will result in
a 100x100 content image.
There is a catch though: GdkPixbuf will only scale *down* to the requested
size, no up. That is, loading a 100x100 image with a requested size of
(200, -1) will result in a 100x100 pixbuf. But as we assume that the pixbuf
size matches the requested size, the image content ends up with 200x100.
Fix this by explicitly handling the case where only one size was supplied,
and make the other dimension take the aspect ratio into account
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/525
The parameters that may affect the icon on ::style-changed are more size
related than visual (we listen to icon theme changes for the latter). It
makes sense to just update the icon if the size came out different.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
With a high enough amount of actors, there may be enough theme nodes and
signal connections on StTheme::custom-stylesheets-changed that
g_signal_handlers_disconnect_by*() on dispose becomes expensive, this may
become a surprisingly hot spot in StWidget::style-changed.
Keep the handler ID around and use g_signal_handler_disconnect() to avoid
linear lookups for the matching func/data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
A window being unmanaged can cause the ShellApp to be removed from
the ShellAppSystem, which if we are unlucky is the app's last
reference, causing it to be disposed and freed. It would be bad if this
happened before we finished handling the signal.
Use g_signal_connect_object to ensure that a reference is held to
the ShellApp for the duration of the signal handler, delaying its
last-unref.
In particular, when a signal handler calls _shell_app_remove_window(),
there is a brief period for which ShellApp breaks the intended
invariant (see !497) that app->running_state is non-NULL if and only if
app->running_state->windows is also non-NULL (non-empty). Freeing the
ShellApp at this point would cause a crash. This seems likely to be the
root cause of <https://gitlab.gnome.org/GNOME/gnome-shell/issues/750>,
<https://gitlab.gnome.org/GNOME/gnome-shell/issues/822> and
<https://bugs.debian.org/926212>.
Signed-off-by: Simon McVittie <smcv@debian.org>
Compare painting/geometry of old and new paint nodes, so it's ensured to
be only emitted on actual style changes. Emission still must be propagated
through to children, though.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1153
Actors themed through CSS should ideally get sizes and positions that
conform to the "pixel grid". A notorious example is the panel that has a
height of 1.86em. On unchanged font settings and hidpi that translates to
55px, which leaves the workarea with "half pixels" that hidpi wayland
applications don't know how to fully cover.
If the requested height is a multiple of the scale factor, the workarea
and maximized applications can then work on full pixels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/91
The same code for reading the current magnifier state is repeated in both
shell-recorder, shell-screenshot and magnifier itself.
So to move this inside a property of st-settings so that we can refer to it
all over the places removing duplications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/473
If the locale doesn't honor strftime()'s %c argument, we would end up
feeding NULLs into GdkPixbuf tagging. Fallback to a sensible (although
not nicely localized) datetime string.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1017
Just like we take a remote "new-window" action into account for
opening new windows, we should call an explicit "quit" action
before falling back to closing all the app's windows on quit.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
For window backed apps, create_icon_texture() doesn't return an StIcon
but a generic widget. Set an appropriate style class to make it easier
to apply a specific style only to fallback icons.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
With StImageContent, the meaning of passing -1 as size parameter changed
from "load the image at its preferred size" to "abort the session". It
is therefore no longer possible to just load the image and then have it
scaled by applying a CSS size to the texture's parent.
Setting the size from CSS is useful though, so to still allow that, fall
back to the actor's size (which can be determined by the style).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
We need this to run `test-theme`, otherwise when run as part of the
build tests it fails like:
error while loading shared libraries: libmutter-cogl-4.so.0: cannot
open shared object file: No such file or directory
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/442
The executable is assumed to be run from $top_srcdir/src, which is
essentially an autotools left-over (it's where the program ended
up with srcdir == builddir).
Now with meson, its actual srcdir makes more senses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
Clutter no longer hard-codes a resolution of 96 DPI (although that's
still the default), so any assertions of sizes for physical units
may be off.
Fix this by setting up the test environment according to the
assumptions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
Since we started to support tray icons on wayland, the icon we show
is not the actual XEmbed window. Instead, we let mutter create a
MetaWindow for it, then use its window actor as source for a clone
we (or nowadays: extensions) can add, remove and destroy freely.
To not let the real icon get in the way, we set an empty input shape
and make its window actor fully transparent. This works OK on X11,
but on wayland all events still go through Clutter, so any reactive
surface actor inside the window actor will block events for any actors
underneath (and status icons go into the top-windows group, so almost
all actors are affected).
Luckily we can pile another hack onto the pile of status icon hacks ...
https://gitlab.gnome.org/GNOME/gnome-shell/issues/191
While mapping the :first/:last-child pseudo classes directly to the
ClutterActor:first-child/:last-child properties allows for an easy
implementation, it is unexpected that rules can appear to not have
an effect because the selected child is hidden. GTK's behavior of
applying the classes to visible children makes much more sense, so
change our implementation to do the same.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/312
When we grab a screenshot of a framebuffer scaled shell, we shoudl apply the
device scale to the image surface, while the monitor scaling should be applied
to the cursor surface, so that it's painted at proper coordinates and in proper
size in the generated image.
This is not needed for XWayland clients as they are not scaled anyways, while
for wayland clients that are painted in multiple monitors, this might cause
a lower quality cursor in the lower dpi monitor, because the cursor sprite is
generated for the monitor scale, and not for the surface scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Under wayland, if the cursor should be included when doing a fullscreen
screenshot, we can rely on mutter "paint" signal to have it composited for free.
Otherwise if it's not requested, we can use the "actors-painted" signal to get a
stage texture before the mouse overlay has been added.
Instead, under X11 or when only a window screenshot is requested, we still
need to draw it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Get from clutter the capture sizes and scale and don't mind
about doing any rounding here, as it might be different
from the one done at clutter level (causing mismatch and
not-working videos). Delegate this to clutter, and forget
about the internal details.
These values are then used to composte the image and set the video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=7650111
It might happen that the target clutter actor that we return on call
of st_texture_cache_load_sliced_image might be destroyed while the
loading task is still running. To protect from this, let's connect
to "destroy" signal and when this happens we use a cancellable to
stop the task.
This allows to safely reuse the return value of this function to
cancel the execution and avoiding that load_callback is called
even for a request that is not anymore under our control.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When loading an actor for a sliced image actor, we can now use the
REQUEST_CONTENT_SIZE request-mode for the actor since we the content image
has now a predictable size and thus we can be sure that the size will be applied
taking care of the resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Create StImageContent as a simple ClutterImage with preferred width/height
properties in order to be able to use explicit sizing when creating clutter
contents that will be applied to actors whose size depends on the content itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
Create the surfaces for background shadows at scaled sizes and then draw on them
using logical coordinates, by setting the surface device scale accordingly.
Use the said surface scale when generating the actual shadow cairo pattern
but in such case, to reduce the number of code changes, is better to work in
absolute coordinates, and to do so:
1) Create a temporary shadow-spec copy with scaled values to absolute sizes
2) Invert the scaling on the shadow matrix
3) Do the actual painting in absolute coordinates
4) Set the shadow matrix scaling back to the logical coordinates.
Finally scale down the created shadow pattern surface size when painting it,
applying again a reverse scale to the matrix.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Pass resource-scale to drawing phase, and use it to create texture
surfaces scaled with the widget current scaling.
Also redraw by default widgets when the resource scale changes.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
A fractional resource scale would mean we never use the fast path for
creating the shadow, because we'd cast the int to a float before
comparing, which would never match.
Instead compare the expected texture size with the source texture, to
actually potentially trigger the fast path.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The fade shader will draw the fade effect up until the border pixel. If
we set the bottom right coordinate to the outer edge of the pixel we
might end up not drawing the fade effect on all of the pixels. This
could for example happen if one logical pixel (clutter stage pixel)
consists of more than one physical pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This commit makes StWidget manage the scale of which its associated
resources should be multiplied with. The resource scale is calculated
by clutter, and is retrieved by clutter_actor_get_resource_scale(). Due
to the resource scale not always being available, the getter may fail,
and the actual widget that draws the content will have to deal with
this situation.
As the resource scale depends on where on the stage the widget is drawn,
the resource scale will in general be available once the widget is
mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
instead of explicit screen arguments and `gdk_screen_get_number()`, as nowadays there
is always only one screen. This silences some deprecation warnings and removes
deprecated API.
Bonus: some code style cleanups
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/422
Since commit deec0bf255, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.
Set up the actor to follow the content's size instead, to get closer
to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/402
As the app menu is being phased out, it is no longer a good indicator
for GtkApplications. Instead, base the check directly on the appropriate
D-Bus properties.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
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
All adjustment setter functions take good care of avoiding emission of
notify:: when it's not needed. The set_property() implementation already
calls into the setter functions, so mark the properties as EXPLICITY_NOTIFY
in order to optimize notify:: emission away through g_object_set (rather
common from JS code).
The actor allocation doesn't change per-se, but apply_transform()
will practically transform it. In order to have the paint volume
update accordingly, queue a relayout.
The default get_paint_volume() implementation will do the union
of children, and the child ClutterText paint volume may expand
beyond StEntry size when text overflows.
We actually want all content to be clipped to the StEntry, so
implement get_paint_volume() and tell it so.
And constrain it in StScrollView instead (instead of falling back to an
infinite paint volume, as the actor as paint/pick impls, but no
corresponding get_paint_volume one).
Fixes artifacts with the AppView (and possibly other places) when paint
volumes are aggressively cached.
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
