The non-interactive requests for 'vpn' settings are forwarded to the UI because
it is able to talk to the auth helpers. However, the VPN requests are identified
by the connection type instead of setting type. That is incorrect and the UI
is not prepared to handle such requests; tries to construct a dialog and fails
miserably:
Gjs-Message: JS LOG: Invalid connection type: vpn
(gnome-shell:13133): Gjs-WARNING **: JS ERROR: Error: No property 'text' in property list (or its value was undefined)
NetworkSecretDialog<._init@resource:///org/gnome/shell/ui/components/networkAgent.js:60
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_Base.prototype._construct@resource:///org/gnome/gjs/modules/lang.js:110
Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:204
NetworkAgent<._handleRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:724
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NetworkAgent<._newRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:715
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=760999
This never worked since the code landed but apparently no-one noticed
until now.
The intent here is to return the accessible's default role if none has
been explicitly set on the StWidget instance.
https://bugzilla.gnome.org/show_bug.cgi?id=760945
Commit ffe4eaf00d changed this code to
call st_widget_get_accessible_role() instead of using the value
directly which would be an infinite recursion if that function didn't
have a bug. As it is, this just resulted in
CRITICAL **: atk_object_get_role: assertion 'ATK_IS_OBJECT
(accessible)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=760945
In get_secrets_keyring_cb, we own a ref on the 'attributes' hash table
from secret_item_get_attributes), and a ref on the 'secret' object (from
secret_item_get_secret(), but in the SHELL_KEYRING_SK_TAG case, we unref
these once before breaking out of the loop, and the second time after
breaking out of the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=759708
Since commit 48a54e8ac4, paint() has an explicit framebuffer parameter,
however a couple of submethods are still using the draw framebuffer,
which breaks when rendering to an offscreen buffer.
The polkit agent does not take ownership of the request's cancellable,
so it may no longer be valid after the request finished and we need
to disconnect it before that. Before the GTask port in 8b4249ef2,
it was safe to do that when freeing the request data because requests
completed in an idle, but now we need to do it before returning the
task result.
https://bugzilla.gnome.org/show_bug.cgi?id=757668
If we are trying to render a shadow at a size that is very large in one
direction, but small in the other direction (so that we don't 9-slice
the texture), then allocating the backing texture for the offscreen
buffer may fail due to texture-size limits. Don't crash in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=757150
There are quite a few crashes in retrace.fedoraproject.org that are a result of
of cairo_pattern_get_surface() failing, then a subsequent call to
cairo_image_surface_get_width() crashing because no surface was returned to the
out parameter. Knowing what causes these is hard - my best guess is widgets getting
allocated at ridiculous sizes - but avoiding the crash makes sense in any case.
See https://bugzilla.redhat.com/show_bug.cgi?id=1206754https://bugzilla.gnome.org/show_bug.cgi?id=756983
The text-scaling-factor GSetting was not being properly propagated
to clutter and the Pango font map; under X this is done by Clutter,
which listens to XSETTINGS directly.
https://bugzilla.gnome.org/show_bug.cgi?id=756447
gdk_window_set_composited() is deprecated, and we don't need it as
we end up setting it to the default anyway.
We do need gtk_widget_set_double_buffered() though, which has been
deprecated as well because it is only meaningful on X11 - but so
is XEmbed, so just shut up that warning.
Composite is a hard requirement for mutter's compositor, so if we get
to the point of managing the tray, we already know that the extension
is supported. So let's get rid of yet another deprecation warning.
It has been deprecated for a while in favor of GdkRgba, though in our
case translating ClutterColors to an intermediate color type before
setting _NET_SYSTEM_TRAY_COLORS is a bit silly, so just move to
ClutterColor as the rest of the code base.
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
Both ShellAppSystem and ShellTrayManager are used as singletons, which
significantly reduces the usefulness of inheritance - it's unlikely for
extensions to inherit from them anyway (AND use any of the vfuncs), so
drop them to allow defining the types as final in an upcoming commit.
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
They are unused, as we don't use them ourselves and the class is not
exposed to introspection. Drop them to allow defining the type as final
in an upcoming commit.
There is nothing preventing callers from replacing the internal
layout manager, and as long as the replacement is a (or derives
from) ClutterBoxLayout, everything should work fine except for
losing a bit of automatic property mapping - and the latter is
easily fixable by moving the setup out of the constructor.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
We use the newly introduced feature from Mutter to hook up our own
fullscreen and unfullscreen animations.
To give the illusion of a transition as smooth as possible, we create a
snapshot of the current contents of the actor before its state is
changed, and crossfade between the two states while the size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=707248
The JS code could still be holding on to a reference to a window-backed app
after all windows have vanished. (For example, the dash queues an idle to
refetch apps and display them.) Avoid dying with an error message if we
attempt to activate or otherwise manipulate such a window.
https://bugzilla.gnome.org/show_bug.cgi?id=674799
The default pipeline color is opaque white and blending is turned
off. If we only draw with that color (e.g. because animations are
disabled and we're always drawn with opacity == 255), blending is kept
disabled since cogl_pipeline_set_color() returns early if the color
doesn't change from what was there before.
In our case we always want blending to be enabled which we can achieve
by setting the blending string ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=755827
Since commit 4f1f226828 we only consider buttons clicked when the
release event had a corresponding press event. However as we use
the hover state to check whether a release event actually occurred
on the button, we dismiss any clicks in cases where we missed the
enter event - most likely due to some other actor holding a grab.
Instead, check whether the button contains the event's source, which
should be less error-prone.
https://bugzilla.gnome.org/show_bug.cgi?id=748919
GObject-Introspection started warning for wrong annotations, and
StGenericAccessible::set-current-value has a return value annotation
even if it returns nothing. This generates the warning:
src/st/st-generic-accessible.c:146: Warning: St:
StGenericAccessible::set-current-value: invalid return annotation
Which, coupled with fatal warnings, breaks the Shell build.
It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
When the last interesting window of an app-backed window is removed,
we'll transition it back to STOPPED, but we transition the state and
send out the signal before we clear the running state.
This means that any listeners to the state-changed signal might
encounter a window-backed app that has a running state, but no
windows. If they call, e.g. shell_app_get_name, while in this state,
they'll encounter an assertion fail.
Apps that are starting might have uninteresting windows like splash
screens pop up and then go away (like LibreOffice), even when
startup-notification hasn't completed yet. In those cases, we don't
want to transition the app back to stopped -- it should remain in
the running state.
Our StartUpWMClass heuristics use a StartupWMClass -> .desktop ID
mapping built from the list of all installed applications. In case
of multiple .desktop files setting the same StartupWMClass, we
currently simply pick the last one returned by g_app_info_get_all (),
which can be a bit surprising:
A window with WM_CLASS 'emacs', launched through a .desktop file
named 'emacs.desktop' with a StartupWMClass of 'emacs' maps to ...
'emacsclient.desktop'!
Make this case a bit less random by preferring the app info whose
ID matches the StartupWMClass.
https://bugzilla.gnome.org/show_bug.cgi?id=751541
Use our own locking and queue instead of async_queue.
Implement unlock and unlock_stop to make the create function return
FLUSHING. This is important to be able to pause the pipeline after some
error occured in the pipeline.
Implement start/stop to clear the queue and its state.
Currently GNOME Shell doesn't support mnemonics and prompters may
send labels with it.
Remove the mnemonics indicator for now.
Signed-off-by: Stef Walter <stefw@redhat.com>
* Fixed style issue
https://bugzilla.gnome.org/show_bug.cgi?id=750465
libcaribou was designed to generate X events which works under wayland
sessions for X clients but obviously doesn't work for wayland clients
and for shell chrome.
This patch adds a simple caribou display adapter which inherits from
its X display adapter and allows us to continue to work for X clients
and at the same time makes the OSK work on shell text entries by
sending key events directly to the focused text actor.
Making the OSK work for wayland clients requires much bigger changes
at various levels in the stack and either not using libcaribou or
re-working it substantially so that's left for future work.
https://bugzilla.gnome.org/show_bug.cgi?id=747274
We currently don't have any code either in gnome-shell or
gnome-shell-extensions setting margins directly with the Clutter API.
On the other hand, the current behavior doesn't allow us to remove a
style class with margins and have that be reflected, so removing this
special casing seems like the right thing to do at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=746902
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
The current code assumes that an embedded window will correspond to
a single MetaWindow over the entire lifetime of the icon, which is
incorrect - the embedded window is unmanaged on Unmap and a new
MetaWindow will be created the next time the embedded window is
mapped. As we currently ignore the new MetaWindow completely, it
will be shown normally in the scene instead of the embedded clone
as intended.
Fix this by setting up clone and window actor each time the embedded
window is mapped rather than once in shell_gtk_embed_set_window().
https://bugzilla.gnome.org/show_bug.cgi?id=745824
Each event returned by GetEvents includes the (currently unused)
UID, which is not always enough to unambiguously identify an event
(different calendar sources, recurring events, ...).
As we will start using the property to record events that have been
dismissed and should be persistently hidden from the calendar, change
it to a truly unique ID.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
If users click outside the search entry while it's empty we reset and
thus give up key focus. This means that when using an input method
with candidate popups, interacting with the popup with a mouse click
cancels the current input method context if there's no other text in
the entry besides the preedit string.
To avoid this we can check if the entry has preedit in addition to
checking if it has normal text.
https://bugzilla.gnome.org/show_bug.cgi?id=745167
Commit 5a47ad837b changed the definition of NC_() to include the
message context, so that gettext can correctly disambiguate strings
like "S". However this does only work when gettext actually returns
a translation from the catalogue; if the string is not found, we
need to strip the context again to not have it show up in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=745521
The mode is never set after the removal of the bottom tray, so it
no longer makes sense to pass it to allowKeybinding(). We can also
safely remove it from the ActionModes flags altogether without
requiring a synchronized update with gnome-settings-daemon, as
the latter never used any flag value above LOGIN_SCREEN.
Commit 1c1f63a7d7 changed the shadow
pipeline to use cogl_framebuffer_ortographic() instead of cogl_ortho(),
but the two functions take their arguments in a different order.
Fixes graphical corruption for text shadows in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=745061
When it comes to keybindings or gestures, there's not really a good
reason why popups associated with the top bar should behave differently
from any other shell menus. Just set the action mode generically for
all menus, so actions like screenshots or media-keys start working
with menus like the background- or app launcher context menus.
https://bugzilla.gnome.org/show_bug.cgi?id=745039
This is wasteful, since GResource does not support file monitoring.
Further, doing so will trigger a fallback code path in GLib that polls
every second in a thread, which is doubly wasteful.
https://bugzilla.gnome.org/show_bug.cgi?id=744013
Currently we have been using the vp8 codec because it was the best unencumbered codec at that time. With vp9 we now have a successor that leads to smaller
files at at the same video quality and has been supported by current browsers
for a while.
With the raise of hidpi and 4K displays we need a better codec that handles
those resolutions better, so switch to vp9.
https://bugzilla.gnome.org/show_bug.cgi?id=742744
The lookup table used by get_app_from_window_pid contained only pids of
apps launched by gnome-shell itself, but not pids of apps running before
gnome-shell was (re-)started. Also the pids in that table might not even
be the pid of the process that is actually showing the window if wrapper
scripts are used.
Instead use shell_window_tracker_get_app_from_pid which uses the pids
from the windows themselves.
This removes the only use of launched_pid_to_app which will be removed
in the following commit.
This fixes: https://bugzilla.gnome.org/show_bug.cgi?id=736527
g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded
timeout of 25 seconds, which is insufficient for starting up e-s-r
in certain setups. Avoid a timeout error by starting the service
manually with a longer timeout before hand.
Also demote the error to a warning + exit failure instead of
a crash, to avoid triggering abrt reports.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
Themes - namely the HighContrast one - may now request symbolic
icons rather than fullcolor ones. In order to have recoloring
work as expected in that case, we will need a theme node to pick
up colors from - using an StIcon instead of manually loading a
texture from the cache gives us that for free, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
GTK+ added support for a -gtk-icon-style property in themes to
enforce a particular icon style. Do the same for shell themes
with an -st-icon-style property, with the same set of possible
values as the GTK+ variant:
'requested' - use symbolic or fullcolor icon depending on the
icon name (default)
'regular' - enforce fullcolor icons
'symbolic' - enforce symbolic icons
https://bugzilla.gnome.org/show_bug.cgi?id=740447
The split between st_texture_cache_load_gicon() and load_gicon_with_colors()
no longer makes any sense, so just move the code into the public method.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
Using a separate property to show when the application is busy rather
than cramming it into the state property makes the code clearer. In most
places we only care if an app is running or not, not whether it is
actually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
This simplifies the code and fixes a race where an application could
call g_application_mark_busy() before the shell subscribed to change
notifications on the application's busy state.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
The window actor shouldn't have been picked since it has an empty
input shape, but bugs in mutter weren't properly interpreting that.
Since the Wayland restructure, the MetaWindowActor isn't actually
reactive anymore, it's the MetaSurfaceActorX11, so this code isn't
doing anything.
It's implemented similar to the padding property, but instead of taking
into account the margin values at drawing time in node-drawing, we set
the clutter actor margins in StWidget when the style is computed.
In the case that a CSS margin is not specified, we don't to set a value
of 0 to the clutter actor margin. In this manner it allows to use
Clutter margin values set in the code. However, the margins that are set
both in the code and in the CSS on the same side, the result is
unpredictable.
We avoid to set the clutter actor margin values to 0 if there's no CSS
margin values defined, so we still allow clutter actors to use margin
set in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=728437
GTK+ added a new PolicyType which currently triggers compiler warnings
about unhandled values in switch statements. We also have a use case for
it already, so add support for the new policy type.
https://bugzilla.gnome.org/show_bug.cgi?id=739379
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
