We override the :visible property for the keyboard actor, but don't
provide a corresponding setter. The property is therefore read-only
on the javascript level, and any attempt to set it will fail.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2691
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
We try to make the OSK 1/3rd as big as the monitor. On landscape
layouts we usually get away with it as there's plenty of horizontal
space to enlarge the OSK while keeping the OSK aspect ratio.
In portrait layout, the horizontal space is a lot more scarce so
it means we'll still have plenty of space after making the OSK as
wide as it can possibly be, which will look as odd blank space in
the OSK panel.
In order to fix this, let the OSK panel height be less than 1/3rd
the monitor size if we are dealing with portrait layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2132
It will happen before next map anyway, and most notably at times
actor sizes produce correct results.
Fixes oddities in emoji pager visibility after showing the emoji
panel, moving to another page, and hiding the OSK with the downward
arrow button. The next time the emoji panel would be shown, panels
had a chance to remain invisible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
It is already scheduled to be set on first map. Doing so here triggers
size and theme node checks the actor tree is not ready for, as the
toplevel actor is not yet attached to the stage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/943
We want extended keys to have the same size as their parent key,
but this is currently broken and the keys end up with their
parent key's preferred size (which is smaller than its allocated
size).
This is due to the way ClutterActor's width/height properties work,
which only return the "real" (i.e. allocated) size when the allocation
is valid, and fall back to the preferred size otherwise.
As changing an StWidget's hover state involves adding or removing
the `:hover` pseudo class, this is currently always the case.
Creating the extended keys first means the keyButton's allocation
is probably valid, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1976
Remove setCurrentPage() function, introduce setCurrentPosition() instead,
which allows to have fractional positions.
Make inactive dots smaller, filled and partially transparent, as opposed to
larger and fully opaque active dot. Make dots smaller overall, remove
borders. Interpolate each dot between active and inactive state based on
scroll position.
Make it impossible to "uncheck" the active dot.
Thanks Florian Müllner for parts of the code.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1932https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/843
While we support a reasonable list of layouts nowadays, we don't
include many variants like `fr+oss`. Instead of directly falling
back to the `us` layout, try stripping the variant first, as the
base layout is likely closer to the expectation than `us`.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1907
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
The Keyboard class used to be both a view and controller class, however in order
to make the keyboard a native Clutter.Actor, we need to separate the widget from
the controller class, so that we can manage the actor lifetime from the JS side.
Thus, initialize the keyboard actor on the Keyboard constructor and create a
KeyboardManager class to manage its state and lifetime.
Add proxy methods for the public functions that were used by other shell
components
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
Properties that aren't marked as animatable don't support *implicit*
animations, but they can still be animated with explicit transitions.
Use the newly added convenience method to cut down further on Tweener
usage.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Clutter animations work on GObject properties on animatables. The
last commit took care of the latter by turning all animated objects
into actor subclasses, now it's time to make all properties used
in Tweens into GObject properties.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We have a couple of places where we don't tween the actor, but a
custom property on the delegate object. In order to move those
to Clutter animations, we will need an animatable, so turn those
objects into widget subclasses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
When toggling keyboard various times, we might get an error because trying to
disconnect an idle that isn't set anymore.
This is because when we remove the idle, we don't unset the ID.
Also clear the idle when destroying the keyboard.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
The current page is going to be destroyed as part of _onKeyboardGroupsChanged
cleanup, however we don't unset its pointer, and thus we'd might try to call a
function using an invalidated pointer.
So, unset the this._current_page reference when its get destroyed, connecting
to destroy signal when setting it and disconnecting when changing page.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1281https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/540
We were cleaning up self._groups, but the actors for all previous
groups/layers/modes would remain attached to the aspect container,
simply hidden.
Under some circumstances this can really make the amount of actors
in the shell stage to quickly ramp up, it's not just a "leak" but
also has potential side effects on performance.
We should destroy all child actors of this._aspectContainer, except
the static ones (emoji and keypad).
While at it, fix this._groups re-initialization, as it's actually an
object, not an array.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/523
Closes?: https://gitlab.gnome.org/GNOME/mutter/issues/556
Unlike regular keys that generate key events from a virtual device,
emoji keys rely on the input method to insert the character. However
as the compositor cannot inject IM events into ibus, this only works
in the shell's own entries on X11.
We shouldn't expose mostly broken functionality to the user, so limit
the feature to the wayland session.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1172
It is convenient for the OSK so it eg. doesn't appear centered in the
available space (eg. on very narrow portrait layouts), plus it will also
be convenient to align other AspectContainers to the same baseline.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/439
The menu grabs the key focus when opened, which takes focus away from
whichever actor triggered the keyboard. And as the menu doesn't have
any text entries, the keyboard is popped down as a result.
Prevent this by making the menu items unfocusable, so the keyboard
focus just stays where it is. Considering that the menu is part
of the on-screen keyboard itself, not being keyboard-navigatable
isn't a big deal here.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/171
This keyboard works similar to GTK+'s emoji chooser (actually, both pull
from the same JSON file). Emojis are categorized in sections and variants
and kept in a "model".
The EmojiPager actor then uses this model to generate pages on-the-fly as
the user swipes around. This is an important optimization since the amount
of actors would rival with the rest of the shell otherwise.
The EmojiSelection object puts the EmojiPager, the page indicators and
a KeyContainer with the bottom row of emoji section shortcuts together to
implement the emoji panel as a whole.
The Keyboard object hooked this to an "emoji" key, which is just visible
on the Clutter.InputContentPurpose where showing an emoji would be
meaningful. Otherwise the surrounding buttons are made a bit wider to
cover up for it (i.e. as it was before).
This will be useful as we want other panels (eg. emoji) to preserve aspect
ratio with the rest of the OSK. Separate the aspect ratio management logic
into this container that will be the parent of them all.
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
If the session mode doesn't allow access to Settings, the language
menu should respect that and not expose the "Region & Languages"
panel. Using the dedicated method instead of manually constructing
the menu item takes care of that and makes for less code.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/780
Pretty much like dd4709bb2, BoxPointer's show() and hide()
functions will clash with Clutter.Actor's ones.
In addition to that, on a conceptual level, the current API
is not great, because calling boxPointer.hide() won't result
in boxPointer.actor.visible == false.
For these reasons, rename show() and hide() to open() and
close(). A compatibility layer will be added in a following
commit, warning about the usage of show() and hide().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Emitting it that soon results in JS warnings, as we don't have
everything in place yet. The position-changed signal will be
emitted from other locations as soon as we have it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/464Closes: #464
As strings are guaranteed to use UTF-8 in the GNOME platform, generic
file APIs like g_file_load_contents() return raw data instead. Since
gjs' recent update to mozjs60, this data is now returns as Uint8Array
which cannot simply be treated as string - its toString() method boils
down to arr.join(',') - so use gjs' new ByteArray module to explicitly
convert the data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/179
For windows, the cursor location needs to be adjusted by the frame
offsets. However we cannot assume that there is a window, as the
shell itself can have the key focus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/414
And stop using FocusCaretTracker for caret position purposes. This
new object uses 1) the text-input protocol in wayland and 2) Info
from IBusPanelService for X11 (which is meant to work for XIM too).
This drops the usage of AtspiEventListener for OSK purposes, which
is best to avoid.
