ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When an InputSourceIndicator is destroyed, the InputSourceManager it was
connected to could (and probably will) outlive it (since the manager is
a singleton). If the InputSourceManager emits any subsequent signals,
the callbacks from the finalised InputSourceIndicator could be invoked,
and will reference finalised objects.
This can be triggered by running `pkexec true` from a gnome-terminal
window, then calling `pkill pkexec` from another terminal (on a
different VT or via SSH). This causes the dialogue to be cancelled by
polkitd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/357
When gnome-shell receives the signal of 'set-content-type' from ibus,
gnome-shell calls KeyboardManager.holdKeyboard() and
KeyboardManager.releaseKeyboard() and the functions change the current
input focus in GNOME Xorg and it could result in closing a popup window
which has a password entry by focusing on the entry.
The solution is to stop to call the APIs on 'set-content-type' signal.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/391
This is the last remaining usage of Shell.GenericContainer
in the codebase, and posed small challenges compared to the
other removals.
A new St.Widget subclass called InputSourceIndicatorContainer
was added as a replacement to the Shell.GenericContainer. It
was needed because GNOME Shell needs to override the regular
size allocation functions, but InputSourceIndicator already
is a St.Widget with its own size allocation overrides.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
In the process of purging all usages of Shell.GenericContainer
of GNOME Shell, one specific problematic situation that might
occur is when classes have functions that would clash with any
ClutterActor or StWidget function name.
One of such example is SwitcherPopup.destroy(). Right now, this
class is a pure JavaScript class that wraps a real actor, but
soon this will change, and it'll become a St.Widget subclass.
Another problem with functions that mimic the toolkit ones is
the predictability of them; after calling destroy(), that widget
is expected to not be available anymore. In SwitcherPopup case,
it is still available for a short while. In this case, that's not
a big problem, but the show() and hide() functions in other clases
are more problematic because the actor's visibility does not
follow that.
This commit is a first step in cleaning that up, and changes the
SwitcherPopup.destroy() to fadeAndDestroy().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
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
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
imports.misc.ibusManager.IBus is declared as const, so referencing it
from another module triggers a warning with recent mozjs. As of commit
083d11a032 IBus is mandatory, so just make it a regular import to avoid
the warning.
Currently the language options displayed pretty much mirror those of the
top bar keyboard layout selection popup. It may make sense in the future
to only list languages, and automatically switch to the enabled IMs that
the OSK can benefit from (eg. by filling in suggestions).
In the current code it could happen that we've menuItems and indicatorLabels
for sources that aren't anymore around, because in case a source is removed
we don't cleanup the their container objects.
Also, we should nullify InputManager's _currentSource when sources change
or it might point to some invalid data again.
So it could happen that we try to access an invalid menuitem or label
if a source change happens mentioning a source that has been deleted.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Instead of saving only the current input source when entering password
mode, let's save the whole MRU list so that we can restore it when
returning to normal mode.
This is closer to user expectations since password mode is a transient
and short lived state.
https://bugzilla.gnome.org/show_bug.cgi?id=746605
g-s-d has been taking care of this for us but in a very hackish way
that causes dconf writes on every startup and also doesn't handle
dynamic updates to locale1's properties which has become a problem now
that GDM keeps its greeter session running in parallel with users'.
To take care of this properly, this commit introduces a settings
abstraction with both system and session implementations. The session
implementation just wraps access to the existing gsettings while the
system one gets its values from org.freedesktop.locale1's properties.
https://bugzilla.gnome.org/show_bug.cgi?id=746288
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.
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
Normally users switch xkb input sources and ibus input sources.
But currently the first input source only is running. It's also good
to preload all ibus engines in the logging session so that users switch
input sources quickly without the launching time of input sources.
The following is the ibus change:
https://github.com/ibus/ibus/commit/cff35929a9https://bugzilla.gnome.org/show_bug.cgi?id=695428
Most of the code handles the sources setting being empty and
InputSourceManager.currentSource being null because previously the
"model" (i.e. the sources list) was kept in gnome-settings-daemon.
But this is fragile and since we're now the canonical place where the
list lives we can force it to never be empty even if the gsetting is
empty or contains only invalid entries. Adding the default keyboard
layout in that case is the safest thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=738303
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
We don't really need this step as a separate method since all
implementations are supposed to be created and shown immediately. This
also ensures that we have items to show in all subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=735976
All derived classes are already checking explicitly for action names
(FOO and FOO_BACKWARDS). mutter used to have a META_KEY_BINDING_REVERSES
flag for keybindings which required special handling of "shift"+FOO as
FOO_BACKWARDS, but this has been removed now, so this special handling
is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
When this flag is set on a MetaKeyBinding, mutter will know that
the keybinding has an associated reverse keybinding triggered with
the shift modifier. However, an undesirable side-effect is that
gnome-control-center keyboard panel does not know that this 'shift'
is reserved for these reverse keybindings and cannot detect
conflicting bindings in this case.
This 'reverse' logic can now be handled at a higher level (in gcc keyboard
panel) so this commit removes it from gnome-shell so that they do not
conflict.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
Now that mutter gives a way to check if a MetaKeyBinding was marked as
'reversed' or not, gnome-shell does not have to hardcode that a
MetaKeyBinding using a shift modifier is reversed, it can directly check
if the appropriate flag is set.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
The code currently tries to use Meta.KeyBindingFlags.REVERSED. Since
this constant is |'ed with Meta.KeyBindingFlags.REVERSES, gjs silently
ignores the unknown flag.
https://bugzilla.gnome.org/show_bug.cgi?id=731619
Until now the arrows were the associated arrow
character of the font. This cause some problems like
different arrows for different fonts, and size can be
altered because of the font size.
To solve that, use an image for the arrows.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Since the agregate menu does 120% of font-size, make this
for all dropdown arrows in gnome-shell and rename the css
class to make clear that it is used in overall gnome-shell
https://bugzilla.gnome.org/show_bug.cgi?id=709564
To align the arrows, we need to allocate panel buttons the full
height of the tray. Fix up all of the panel buttons to support this,
and align the arrows in the middle.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
This is a singleton object inside libibus which means that if we
destroy it (e.g. because ibus-daemon got restarted) then, other
library users, like the ibus gtk+ IM module that we also use
in-process, will break.
https://bugzilla.gnome.org/show_bug.cgi?id=699189
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
StLabel doesn't like that we set its properties after destructions,
and this would happen in currentInputSourceChanged() at the end,
when setting the ornament.
When we switch into an invalid input source we hide the panel
indicator and return early but we were not hiding the previously
active source label and its menu item dot and thus when switching
again to a third input source we would end up showing 2 overlapping
labels in the panel and the menu would have 2 entries with a dot.
https://bugzilla.gnome.org/show_bug.cgi?id=695841
SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.
This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.
https://bugzilla.gnome.org/show_bug.cgi?id=693907
While we handle the case where ibus_bus_get_global_engine() returns
NULL, this case actually generates an exception we have to catch to
avoid some (harmless) console spam.
https://bugzilla.gnome.org/show_bug.cgi?id=692995
If the setting is enabled, we record the last activated input source
for the currently focused window and switch to it when focusing back
that window. The Overview is considered a window for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=691414
Instead of storing them globally and having an hardcoded list of
engines which are allowed to change their indicator symbol when the
InputMode property changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682318
Due to the way the IBus API works we might get property changes while
the menu is already open. In that case the separator visibility logic
doesn't work since it only applies on menu open/close. This works
around that issue.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
IBus has a properties API which are basically generic knobs into the
engine which are serialized and presented in a way that allows us to
easily build actionable UI elements with them.
Instead of implementing the whole generic system and accepting
everything coming out of the engines, for now, this patch just adds
support for a couple of important IBus Anthy properties.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Track locked status and use it to provide a reduced version of
the panel in the locked screen. Accessibility, input sources and
volume menus are preserved, without the link to the control center.
Network, battery and user menu are reduced to pure indicators,
with no menu.
This is similar to the design but not exactly, because designers
in IRC said that network needs more analysis before exposing, and
because the design didn't account for a11y and IM (so the one menu
metaphor is not really appropriate).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
We connect to the IBus daemon asyncronously and use it to query info
about input sources of the type 'ibus'. In case the daemon is or
becomes unreachable we just skip showing input sources of this type.
https://bugzilla.gnome.org/show_bug.cgi?id=641531
Rather than accessing global.session_type / global.session_mode
all over the place, delegate mode information to a dedicated
sessionMode object. While not very useful for now, we will replace
checks for a particular mode with checks for particular properties
that sessionMode defines based on global.session_mode.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
