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
The pointer to ->accessible was cleared too early in dispose, which
resulted in another accessible object being created when the actor
was removed from its parent in clutter_actor_dispose(). Use a
weak reference instead to clear the ->accessible pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=738147
Wayland applications don't tend to have very useful WM Class properties,
as GTK+ isn't very good at picking an appropriate application ID. While
we should likely fix GTK+ to pick a better app ID, we do have the
existing gtk_shell for more accurate information. The only problem is
that the gtk_surface is set after the MetaWindow is constructed, and
we're not listening for changes on the GTK+ application ID.
Listen to changes on the GTK+ application ID to fix app tracking for
most GTK+ applications under Wayland.
We currently allow infinite number of screenshot requests to be active at
the same time, which can "dos" the system and cause OOM.
So fail subsequent requests for the same sender when a screenshot operation
is already running.
https://bugzilla.gnome.org/show_bug.cgi?id=737456
These keybindings are well-established on the CLI (e.g. "kill-line"
and "unix-line-discard" in readline(3)), and adding support for them
is cheap ...
https://bugzilla.gnome.org/show_bug.cgi?id=737346
All current code assumes that the list of window actors corresponds to the
list of windows; however as the list returned by meta_get_window_actors()
now includes actors during the destroy animation, that assumption breaks.
Eventually we should make everyone move to a more appropriate API, but
for now make it work again by returning a filtered list of "good"
window actors.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
Performance testing was producing inconsistent values at different
times in the day since the GNOME default background is animated and
sometimes has a single layer, and sometimes two blended layers.
So we have consistent numbers, install a simple animated background
with GNOME Shell that has 40-year long transition ending in 2030,a
and set an environment variable in gnome-shell-perf-tool so that the
background is override with that background. (The background depends
on files installed by gnome-backgrounds; we assume that the person
running performance tests is doing so within the scope of a full
GNOME install.)
https://bugzilla.gnome.org/show_bug.cgi?id=734610
If the application reports itself as single window (through
an explicit indication in the desktop file or some heuristics),
not show a "New window" item that doesn't actually open a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=722554
Add a --hwtest option to gnome-shell-perf-helper which runs the
tests in perf/hwtest.js with the appropriate environment, and then
logs the results using the 'gnome-hwtest-log' utility which is
available in the hardware testing environent.
(For development of hwtest.js in a normal environment, run the tests
as: gnome-shell-perf-tool --perf=hwtest --extra-filter=Gedit)
https://bugzilla.gnome.org/show_bug.cgi?id=732350
It's useful to know how long frames are taking to render on the GPU.
This is impossible to measure in the normal case because frames may
parallelize with previous frames, but by calling glFinish() at the
end of the frame, we can create a (somewhat artificial, but useful)
environment where we have a meaningful timestamp for the frame
finishing drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
Instead of always logging frame timestamps for every frame - which
was using >26 bytes of memory per frame, or 5MB per hour of continuous
redrawing - make frame timestamps something that defaults off and is
turned turned on using a new ShellGlobal::frame-timestamps property by
the perf scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
Add an option for windows created with Scripting.createTestWindow()
to continually redraw themselves; this is for testing performance
of application updates.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
On X11 we don't need to scale up fonts because font scaling is already handled
by clutter based xft-dpi. On wayland we need to set the resolution by ourselves
so do that when the scale factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=732537
Add a small DBus-activated GtkApplication that embeds a WebKitWebView
and implements some minimal logic to see if the login succeeds.
It will try to connect to a custom NM-provided url (the portal login
page), if one exists, or to www.gnome.org in the normal case of
a portal doing redirect.
https://bugzilla.gnome.org/show_bug.cgi?id=704416
This reverts commit e23c2ffecc.
The patch was intended as a cleanup but accidently removed the setting of the
event base, breaking the swap event handling.
With the event base setting removing the other code isn't much of a cleanup so
just revert it.
Send EOS to the complete pipeline instead of only to our own source.
When there are multiple sources in the pipeline (for example when we also
record audio), the pipeline will send the EOS to all sources in order to
shut down the complete pipeline.
Commit 6c2f3d1d17 moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.
Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
https://bugzilla.gnome.org/show_bug.cgi?id=695487
Having the full geometry of the menu's source button (if any) will
allow us to address several misbehaviors of window menus, so use
that instead of show_menu().
https://bugzilla.gnome.org/show_bug.cgi?id=731058
Rework the way we re-exec the shell on OpenBSD so that it does not only
work the first time it is re-exec'd.
Plug a small leak in the __linux__ case while here.
https://bugzilla.gnome.org/show_bug.cgi?id=727763
We now allow "appmenu" in the button layout to make synchronizing it
with GTK+'s client-side decorations easier, but as some people tweak
their settings to get in-window app menus even when using the shell,
actually pop up the app menu when the button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
The switch to GNOME_COMPILE_WARNINGS() caused -Wall and other
warnings to not actually be used since GNOME_COMPILE_WARNINGS()
just sets WARN_CFLAGS. Add WARN_CFLAGS to AM_CFLAGS so that
it takes effect.
Add -Wno-error=deprecated-declarations so that when -Werror is
enabled, we don't fail on all the deprecated cogl and clutter
symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=730408
It can be useful to augment the shell's search path by doing
GNOME_SHELL_JS=resource:///org/gnome/shell:<mypath>
But this doesn't work because resource: is split off. Special
case path elements that are just 'resource' and recombine
them with the next element.
https://bugzilla.gnome.org/show_bug.cgi?id=730409
The hover state of a widget can become persistent if
the widget becomes reactive while a pointer grab.
To avoid that, remove hover state if the reactive property
is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=728343
We need to use a GdkPixbufLoader instead of the straightforward
gdk_pixbuf_new_from_file(), since we want to load the image already
scaled if possible - e.g. if it's an SVG file.
https://bugzilla.gnome.org/show_bug.cgi?id=726907
Since rebasing our AppSystem on GLib's facilities, we only ever
append to the id-to-app cache. So if an application is uninstalled,
shell_app_system_lookup_app() will still happily return it if it
was cached previously. For instance if a favorite app is uninstalled,
it keeps lurking in the dash until a restart.
To fix, filter out removed apps from the cache when handling
GAppInfoMonitor::installed-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=726414
Currently we update the scale factor on startup and when we get a
monitors-changed signal, which is not the only cases where the setting changes. We cannot listen for gdk-window-scaling-factor changes because it is not
exported to gdk.
So use gtk-xft-dpi which also indicates a scale factor change.
When someone changes gtk-xft-dpi directly without changing the scale factor
we will just re-read the gdk-window-scaling-factor so no harm is done.
https://bugzilla.gnome.org/show_bug.cgi?id=726238
It's possible that FBO creation fails due to hw limits or the
driver not exposing the EXT_framebuffer_object extension.
In that case, just give up on creating square icons.
https://bugzilla.gnome.org/show_bug.cgi?id=724977
Instead of poking through IDLETIME, which confuses the state tracking
and can prevent automatic suspend, send a special signal to GSD
when the screen is to be waken up for a notification.
Someday we'll bring over all the state tracking and avoid this
ping-pong between gnome-shell and gnome-settings-daemon, but
that day's not today.
https://bugzilla.gnome.org/show_bug.cgi?id=712706
While the named commit was correct for VPN connections, it didn't
work correctly for the initial secrets requests like when connecting
to a new access point. In that case, secrets *should* be requested
when none are found, but only if interaction is enabled. The
bits of 17726abb which removed checking secrets against the hints
*were* correct, but 17726abb removed too much.
Also, to ensure passwords don't get inadvertently cleared when
simply reading them from the keyring, don't save passwords
unless something might have changed.
https://bugzilla.gnome.org/show_bug.cgi?id=724779
Currently running the perf tool results into no wm running
afterwards making it hard for the user to get the results from a terminal
and generally does not make it easy for users to run it to gather numbers.
So restore the shell after the test has completed.
https://bugzilla.gnome.org/show_bug.cgi?id=724870
clutter_device_manager_get_core_device calls XIGetClientPointer, which
requires a round-trip to the server. Since we do this on StWidget
creation, this means a full round-trip for every created StWidget.
Replace this with get_device with the ID of the VCP/VCK, since mutter
doesn't support MPX, and we know this is what the device is.
If the sprite is NULL, like if a Wayland app wanted to hide the cursor,
then we need to hide the ClutterTexture on our side, as ClutterTexture
has no easy way to tell it to paint nothing.
If gdk_screen_get_setting fails, like if it's running without XSettings,
then the GValue will have a value of 0. A lot of code tries to divide by
the scale factor. This produces NaN, and combined with the fact that NaN
is "leaky", we very quickly end up spinning out of control.
jsapi.h has some bad warnings with gcc. gjs-module.h already includes
jsapi.h and uses a complicated set of GCC pragmas to mask them out, so
just kill our include.
Since we started tracking non-interesting windows, we can no longer
assume that if we manage to find an app associated with the focus window,
it should appear focused - we now can find apps for docks, the DESKTOP
window etc.
To restore the old behavior, make sure that the focus window or one of
its parents is "interesting".
https://bugzilla.gnome.org/show_bug.cgi?id=722928
