After we receive one of the tracked signals, in case we get stuck inside
the gjs_dumpstack () call, we use an alarm to raise the previously emitted
signal, however without using SA_NODEFER, the raise inside the alarm handler
will be ignored.
To avoid to handle new signals caused by the handler calls, once we get the
first signal, we just ignore them all as they could only lead to dirty traces.
Also, cleaning up a bit the code, and disabling the shell log handler
in dump_gjs_stack_alarm_sigaction since this might lead to a new
gjs_dumpstack () request.
https://bugzilla.gnome.org/show_bug.cgi?id=789237
In order to debug issues triggered by JS code we might need to
see the stack of it, this is not normally visible in static stack traces,
thus we need to call gjs_dumpstack () before dying the process.
Intercepting signals SIGABRT, SIGTRAP (needed for catching fatal glib
errors) SIGFPE and SIGIOT by default, while introducing a new
'backtrace-segfaults' flag for the SHELL_DEBUG environment variable to
do the same on SIGSEGV and SIGBUS (this is a precaution to avoid that we
corrupt the stack for automatic errors trackers).
In any case after dumping the stack we raise the signal again, in order
to make the system aware of it.
https://bugzilla.gnome.org/show_bug.cgi?id=789237
Similar to what it's done in _shell_app_add_window(), rely on calling
shell_app_sync_running_state() when removing windows too, to avoid
transitioning to STOPPED while it's still in the STARTING state.
This makes the logic compliant with the startup notification spec and
prevents stopping an application too early if it has a splash screen
that has been closed before the application's main window is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=787905
Meson now warns when specifying the rpath in linker flags instead
of using the newly added build_rpath option - now that we already
depend on the latest release, there's no reason anyway to not use
the nicer syntax.
https://bugzilla.gnome.org/show_bug.cgi?id=786343
When creating a shadow for a ClutterTexture, we currently use the
underlying CoglTexture directly instead of rendering the actor to
an offscreen buffer. This assumes that the CoglTexture is directly
suitable as shadow source, which isn't necessarily the case - it
may have a very different size than what is shown and scaled up or
down by the hardware. In that case we end up with a scaled shadow
texture as well, which messes up the desired blur effect - the
result will be too light when scaling up, or too sharp when scaling
down. To fix this, only take the shortcut when a ClutterTexture's
underlying texture has the correct size and fall back to offscreen
rendering otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=788039
If a tray icon gets a mapped and unmapped and the mapped again
in quick succession, we can end up with multiple handlers
listening for window creation events.
This commit tries to guard against that by only listening for
window-created events when we don't know the actor associated
with the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=787361
Unlike pango_font_description_from_string(),
pango_font_description_set_family() requires a already properly
formatted font family string. The proper format is a comma seperated
list of font families, but we generated a "comma space" separated list.
Passing a incorrectly formatted font family string to pango seems to
cause wierd issues, where the wrong font is sometimes selected.
For example, this fixes a font selection issue on zh_TW.UTF-8 locale for
chinese characters, where previously the "Droid Sans" font was selected
instead of "Source Han Sans TW" even though fontconfig had placed
"Source Han Sans TW" before "Droid Sans".
https://bugzilla.gnome.org/show_bug.cgi?id=786868
The theme widget passed to shell_tray_manager_manager_screen() is simply
a means to receive style information. There is nothing which ties the two
object's life cycles together, so it is entirely possible for the tray to
be finalized with the widget still around - we shouldn't try to update the
stale object on widget style changes, so make sure we properly disconnect
the signal handler.
https://bugzilla.gnome.org/show_bug.cgi?id=786526
Compiling the generated source for each consumer of the dependency
means we end up trying to register the enum types multiple times,
resulting in a fatal failure on startup. Luckily code outside libst
itself only depends on the header, which doesn't cause those issues.
st_built_sources contains the source and header generated by mkenums,
not any other generated sources. Clarify that in the name, as we are
about to use source and header separately.
We cannot rely on any build order, except the one we specify ourselves.
St depends on various generated files; other targets depend on those
files existing, so they can be included. There is no direct relationship
between targets and files, unless we declare a dependency, using the
Meson declare_dependency() constructor — which allows us to replace the
various `link_with` directives with the more appropriate `dependencies`
one, and also allows us to specify sources that must exist by the time
we build those targets.
In parallel builds we may end up with st-enum-types.c being built inside
separate targets outside of src/st which may not have the ST_COMPILATION
pre-processor symbol defined. For this reason, we need to define it
ourselves in the source file, before including other headers, to avoid
the single-include guard.
This is not strictly necessary when linking the shell with DT_RPATH as
the runtime paths will be extracted from the introspected libraries and
used from gobject introspection to find them when loading them based on
the typelib files, but when linking with DT_RUNPATH, as it's the case
for some linkers (e.g. ld.gold, or ld.bfd in some distros like Debian).
By explicitly prepending this directory as a library path for GIR, we're
making sure that the wrapped shared objects installed in Mutter's and
GNOME Shell's private directories can be found in all cases.
https://bugzilla.gnome.org/show_bug.cgi?id=777519
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
When using the meson build system, gvc will be built as a subproject.
As meson restricts submodules to a subprojects/ directory in the
source tree root, move the submodule there.
https://bugzilla.gnome.org/show_bug.cgi?id=783229
libmutter-clutter fixed stage capturing when views are scaled, and for
that to work properly when compositing the screenshot, we need to deal
with the cairo device scale here too.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Even though the API documentation doesn't say so, the underlying
Cogl texture of a ClutterTexture may be unset, so check for that
case to avoid a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=784353
Otherwise UTC is used which results in a different interpretation of
floating time events. This then could lead to a mismatch with events
generated e_cal_client_generate_instances_sync() which always uses the
default timezone. Such a mismatch would then cause constant invalidation
and reloading.
https://bugzilla.gnome.org/show_bug.cgi?id=781950
This allows a full ClutterActor to be used as hint in the entry, instead
of a simple string.
The string case has been now re-implemented on top of the hint actor.
https://bugzilla.gnome.org/show_bug.cgi?id=783484
This is the same as the previous commit, but for StEntry.
We don't have any need to explicitly destroy this actor in our dispose
implementation, and doing so breaks the assumption that we can access
the clutter_text from within destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
There's no need to explicitly destroy the ClutterText actor inside the
label; doing so is actually harmful, as it will break the normal
reference cycle between container and children.
As StLabel doesn't hold any extra reference to the ClutterText actor and
just uses clutter_actor_add_actor() to add it to itself, let the normal
container dispose cycle run to dispose of the reference.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
The static library was split out to avoid duplicate compilation
of mutter-independent libgnome-shell sources when we had a
wayland/non-wayland split. With the separate libmutter-wayland
library long gone, there's no reason to make the build more
complicated than it needs to be, so fold libgnome-shell-base
back into the regular libgnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=783206
Most of the libsecret API was declared stable in 0.18 and the stable API
now provides everything we need, so switch from libsecret-unstable to
libsecret-1.
https://bugzilla.gnome.org/show_bug.cgi?id=782637
Commit ffe4eaf00d broke the handler by fetching the instance private
from the wrong actor - as we don't use the ::primary-icon-clicked signal,
and the ::secondary-icon-clicked signal still works by accident, nobody
noticed until now ...
https://bugzilla.gnome.org/show_bug.cgi?id=782190
When extracting the sliced image, the GTask grants data ownership on
g_task_propagate_*, so the pixbuf list must be properly freed. On async
load, we just left a dangling reference when returning on the async
task.
https://bugzilla.gnome.org/show_bug.cgi?id=642652
st_theme_node_get_border_image() may return %NULL, leading to a
segfault in st_border_image_get_file() when glib is compiled with
G_DISABLE_CHECKS.
https://bugzilla.gnome.org/show_bug.cgi?id=780381
The built-in telepathy integration is far less prominent than it
used to be, and doesn't really justify a link time dependency to
send debug message over D-Bus.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
We are still using DBUS_NAME_FLAG_REPLACE_EXISTING from dbus-glib
in some places (whose headers are drawn in via telepathy-glib).
As both GIO and dbus-glib use the values that will end up being
sent on the bus, the define and enum value are interchangeable,
but it's clearly better to consistently use the library that is
explicitly included.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Rename the signals which have been used to handle XDnd events to more inclusive
ones. So that these signals can be used to handle the DnD events in Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Mutter now provides versioned libraries and pkg-config files, meaning
an application using libmutter and friends need to depend on a specific
version of the API.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
Solaris 11.3.5 and later have a Linux-compatible implementation of
/proc/self/cmdline, so the code to use it can be enabled in gnome-shell
on Solaris - if used on an older OS, it simply fails to open the file
and returns without doing anything, just as the code did before enabling
this.
https://bugzilla.gnome.org/show_bug.cgi?id=776199
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
It isn't useful to move the keyboard focus to a hidden actor, so
only include visible actors in the focus chain - this is in fact
the documented behavior of st_widget_get_focus_chain(), so having
the default implementation return all children has always been
unexpected.
https://bugzilla.gnome.org/show_bug.cgi?id=778158
This fixes the shell not picking updates to the contents of the underlying
.desktop files for application launchers, or when a .desktop file is
overriden by a user-installed one under ~/.local/share/applications
https://bugzilla.gnome.org/show_bug.cgi?id=773636
After having embedded a Gtk window, we start to listen for the
corresponding MetaWindow to know when it has been mapped by the
compositor. If the embedder does not realize the window immediately,
and some other window is created and mapped before the embedder
realizes the window, we would prior to this patch try to dereference
the not created GdkWindow. Fix this by NULL checking the GdkWindow
before dereferencing. We will never miss the needed MetaWindow creation
since it can not have been mapped have it not yet been realized.
https://bugzilla.gnome.org/show_bug.cgi?id=776130
This will be required in the upcoming version of GJS.
The reference count on ShellGlobal is 2 at this point, because JS holds a
reference due to the "window.global = Shell.Global.get()" line in
ui/environment.js. Therefore, destroy the GjsContext first, then unref
the ShellGlobal object.
Cleaning up ShellGlobal was previously only enabled behind a debug
environment variable, but it should be required now.
https://bugzilla.gnome.org/show_bug.cgi?id=775374
Sliced images are loaded into a group actor with one child actor
per slice. In case loading the image fails, we currently quietly
return the empty group actor, which makes diagnosing problems
unnecessarily hard - just be a bit more verbose on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=774805
This might be a good fit for extension developers: With
this option one doesn't need to restart the whole Shell
in order to see their changes in effect.
https://bugzilla.gnome.org/show_bug.cgi?id=772593
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
You can define a new importer object by importing a subdirectory in GJS.
This is undocumented, but it is likely to at least hold until the whole
thing moves to ES6 modules, after which we'll be able to do this purely
in JS with Reflect.Loader.
Since this was the only thing the ShellJS library did, we can remove it
altogether.
This allows us to discontinue use of the gjs-internals-1.0 embedder API.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
Our window matching currently fails frequently with Flatpak
applications, as one of the primary hints used to link windows
with .desktop files - the WM_CLASS - no longer matches when
flatpak renames the exported .desktop file. Worse, as Flatpak
applications are run in their own PID namespace, different
apps frequently share a common _NET_WM_PID, resulting in
unrelated apps being grouped together by one of the fallback
paths. To match Flatpak applications reliably, take the newly
exported Flatpak ID into account.
https://bugzilla.gnome.org/show_bug.cgi?id=772615
Other windows like the mutter Xwayland selection bridges might deal with
the clipboard, which would result in events visible on st-clipboard event
filters.
In order to avoid unintended results, ignore events that are not meant for
the clipboard window.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
Mutter may capture the screen in multiple capture regions. If this is
done, take these images and composite them onto one large image, which
is then passed into the gstreamer source.
When clutter gives us multiple captures (multiple cairo_surface_t's),
composite them into one large image and use that as final screenshot
result. This makes screenshooting work when mutter uses multiple views.
https://bugzilla.gnome.org/show_bug.cgi?id=770128
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769074
Negative values don't make sense to timestamps, and an unsigned
timestamp as returned by shell_global_get_current_time() or
Gdk/Clutter events may exceed the range of signed integers.
https://bugzilla.gnome.org/show_bug.cgi?id=769216
In commit 7e0e224e0, when moving from e_cal_recur_generate_instances()
to e_cal_client_generate_instances(), the return value of the
ECalRecurInstanceFn callback was accidentally removed; add it
back.
https://bugzilla.gnome.org/show_bug.cgi?id=769156
There is no longer any guarantee that there'll be one single
framebuffer to read pixels from. In order to still read pixels from the
stage, use the new clutter_stage_capture API.
https://bugzilla.gnome.org/show_bug.cgi?id=768979
Instead of querying the client for a list of objects and using
e_cal_recur_generate_instances() to get occurrences for each of
them, we can use e_cal_client_generate_instances_sync() which
combines the functionality of both functions. This doesn't only
save us some lines of code (yay!), but also gives us access to
the real recurrence ID of an event, so we can get rid of the hack
of faking one.
https://bugzilla.gnome.org/show_bug.cgi?id=748226
We use the triplet of source ID, UID and recurrence ID to create
an ID to unambiguously identify an event, which we use to implement
hiding dismissed events from the calendar. However we currently
try to fetch the recurrence ID from the objects returned by
e_cal_client_get_object_list_sync(), which are always the primary
events with no recurrence ID. Instead, we need a recurrence ID
associated with each occurrence.
https://bugzilla.gnome.org/show_bug.cgi?id=748226
