This is pseudo-class is added on .shift-key-uppercase whenever the shift
state is latched, a matching selector would be:
.keyboard-key.shift-key-uppercase:latched {}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Drop the UTF8 glyphs from those, and add style classes so those can be
specifically themed and given a background image. The style classes are:
.keyboard-key.enter-key{}
.keyboard-key.shift-key-lowercase{} /* applies while lowercase */
.keyboard-key.shift-key-uppercase{} /* applies while uppercase */
.keyboard-key.layout-key{}
.keyboard-key.hide-key{}
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Do the finicky checks to adjust key widths and whatnot based on other
values than the label. This makes the label exclusively used for
presentation (i.e. setting up a St.Label).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
Instead of latching all states, make shift unlatched by default, and only
latched when making a long press on the key. When not latched, the keyboard
will switch to the first level (alphabetic lowercase) after the first key
press.
Also, move the actual level switch to Key::pressed, so it feels more
reactive on long press.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
It was mistakenly connecting twice to the 'released' signal. Also, move
level changes to key release, since it will be more convenient to hook
latched states on long press.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
These objects created this.actor being the St.Button, and a surrounding
this.container actor that is the actual actor callers care about. Turn this
around and make this.actor be the parent-less actor, and this.keyButton the
contained internal button. This is more consistent with gnome-shell style.
Commit 8fdf47ea5b removed _addKeys(), but forgot one caller. We just want
to regenerate the keyboard for the current group, so call into the
_onGroupChanged function.
While the scale factor is taken into account for app icons, we set
an explicit size when combining the into a folder icon - unless we
take the factor into account, the result will be too small on HiDPI
displays.
https://bugzilla.gnome.org/show_bug.cgi?id=792259
The captured-event handler just redirects focus there on the first keypress,
what it doesn't account for is that other entries may be active while the
Activities overview is opened (eg. alt-f2, or other modal dialogs). Play
along with other entries, and make it only steal focus if no other entry
is selected.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/33Closes: #33
Similar to what has been done for the apps switcher, this allows closing
windows pressing W or F4 while operating the windows switcher popup or
the apps switcher popup while navigating the list of windows for an app.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
This will be mainly useful for closing apps from the applications
switcher, but can be implemented generically enough to select the
nearest existing item after removal if there's any, or destroying
the popup's actor otherwise.
Specifically for the apps switcher, doing this also removes the need
of having to manually either update the current app in AppSwitcher
and highlight it, if there are still any items after the removal, or
simply destroy the AppSwitcher otherwise. Besides, calling _select()
in the handler for item-removed makes sure that the list of thumbnails
in the switcher is always closed, if open, when quitting the app.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
Make sure that the items from the applications switcher and the windows
switcher are removed when the related applications get stopped, or some
of the associated windows closed.
https://bugzilla.gnome.org/show_bug.cgi?id=620106
glibc 2.27 introduced new format specifiers for the month names.
It's obligatory to use them in several languages already and it's
encouraged to use them for all languages because it is not destructive
for any language. As more languages are expected to follow this
standard it's better to use the "%OB" format specifier now so it will
start working correctly automatically.
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=10871
This standard has been also working in BSD and OS X since 1990s,
if anyone tries to use gnome-shell in these systems.
Note: This will not work correctly with glibc < 2.27, there is no
detection whether the system is old or new.
https://bugzilla.gnome.org/show_bug.cgi?id=780957
We keep track of the lock state and restore it on startup to prevent
a crash from bypassing the screen lock. However on wayland, a crash
doesn't result in gnome-session restarting gnome-shell, but brings
down the entire session - that is, restoring the lock state does not
actually protect the existing session in that case, but forces the
user to authenticate twice in order to start the next session. This
is clearly not helpful, so avoid this by not saving the state when
running as wayland compositor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/17
Align and center the date entry with the workspace's workarea.
This way, maximized applications have their window aligned with the top date
entry.
This doesn't change anything for desktops with no docks or when left/right
workareas are aligned with the monitor.
The offset is leftOffset - rightOffset:
(workArea.x - monitor.x) - (monitor.width - ((workArea.x - monitor.x) +
workArea.width))
https://bugzilla.gnome.org/show_bug.cgi?id=792354
We will now basically act as "policy provider" for thunderbolt
peripherals by using org.freedesktop.bolt service: when new
devices are connect and session is a unlocked user session
we will automatically enroll (authorize and store in the database)
them.
If new devices are connected but the session is locked a message
will be shown informing the user that the device needs to be
reconnected to properly work.
The org.freedesktop.bolt service is provided by the "bolt" daemon.
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).
The focused window will move up/down together with the OSK if the focus
area happens to be covered by the area to be covered by the OSK. This
state is reverted whenever the window loses focus, given it wasn't
relayout in between.
We do not need the parent Keyboard object to handle those specially, the
code can be self-contained enough. The Key object will simply emit
pressed/released events containing the keycode/string, be it from the
parent key or one contained in the BoxPointer.
StIMText used to handle key events for IM consumption in the capture phase,
this made the search box work automagically with nothing explicitly focusing
it. Since it's no longer the case, it has to be done somewhere.
Instead of manually resizing each key everytime the keyboard needs to
relayout, have a special grid container that will preserve aspect when
resized.
This actor works in two stages though, first the keys need to be added
and then layoutButtons() need to be called for the actors to be
reparented to the container with the right attachment options.
This is a ClutterInputMethod implementation using IBus underneath. The
input method will interact with the currently focused ClutterInputFocus,
be it shell chrome or wayland clients through the text_input protocol.
The keys possibly need resizing after a (new) layer has been set, there's
however calling places that don't. Instead, fold this._redraw() into
setActiveLayer().
Getting the necessary "setting enabled, or input from touchscreen"
conditions to have the OSK shown are not enough on the lack of a
current focus. As we are setting up the caret tracker here, wait for
the focus in event before showing the keyboard.
This fixes 2 issues, with the setting disabled it became really hard
to get the OSK hidden on eg. touchscreen->pointer device switches,
as visibility only depended on the a11y setting here. And secondly,
enabling the setting would always end up with the OSK being shown
regardless of focus, while it should stay hidden if there's no text
edition.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
If the underlying X11 input driver creates multiple devices from a single
device node, we may end up picking up the wrong device. So, instead of
picking the first device based on node and bailing out if it's not a pad,
pick the first pad that has that device node, and bail out if there is
none.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/10Closes: #10
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
We want touch events to enable the keyboard and focus tracking, but
not to actually show it right away. Implement that behavior by only
changing the visibility of the keyboard when triggered by a GSettings
change.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
We enable the keyboard when it is either enabled explicitly via
a11y settings or when using a touch device. We'll soon want to
special-case changes to the GSettings, so track its value in a
dedicated property.
https://bugzilla.gnome.org/show_bug.cgi?id=788188
When the agent doesn't work (e.g. when the screen is locked), it shouldn't be
registered with NM. Otherwise it will keep cancelling the requests that
could happily be serviced with system secrets.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
The native agent already forgets about the request at the point it's
serviced and the further attempt to use it (e.g. cancel it when the screen
is locked) will trigger an assertion failure:
** (gnome-shell:30862): CRITICAL **: shell_network_agent_respond: assertion 'request != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=789811
Show a dialog informing the user each time the keyboard accessibility
flags are changed by one of the clutter backends (either from toggle
keys or two-keys-off modifiers).
https://bugzilla.gnome.org/show_bug.cgi?id=788564
The background code allocates a GnomeWallClock when its first created,
but neglects to drop a reference to that clock at destroy time.
The undestroyed clocks lead to a timerfd leak that eventually prevents
the shell from functioning.
https://bugzilla.gnome.org/show_bug.cgi?id=791655
If there are locations unknown to the libgweather version gnome-shell is
using, don't crash.
JS ERROR: TypeError: b.location is null
WorldClocksSection<._clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:141:1
WorldClocksSection<._clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:139:9
https://bugzilla.gnome.org/show_bug.cgi?id=791148
Since commit ef1e27966d turned DashItemContainer into an StWidget,
the destroy() method overrides the ClutterActor method, which is at
the very least bad style. Instead, follow the usual pattern of using
a ::destroy handler.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Labels are currently destroyed from both animateOutAndDestroy()
and destroy(), which now (rightfully) triggers a gjs warning. As
the label is created unconditionally since commit 36e5ae4a25,
mirror that and always release it in destroy() and hide it
elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
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
These end up emitting item-drag-end/window-drag-end pretty much
without checks. Given the MetaDnd object may end up emitting
::drag-leave as a result of the plugin ending its grab, this
would result on spurious emission of those events and subsequent
warnings.
For extra paranoia, the _inDrag variable has been split into
_inItemDrag/_inWindowDrag so we can't cross the streams.
https://bugzilla.gnome.org/show_bug.cgi?id=784545
While window attention notifications are created by the shell itself
rather than applications (most likely as a result of focus stealing
prevention), users still commonly link them to the application for
which they are shown. It makes therefore sense to follow the appropriate
policy set by the user rather than showing them unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=779974
Since 0b02f757f8 we track the button that should have key focus
when the dialog is opened. However when the dialog is reused, the
button may get destroyed - clear the initial focus in that case to
allow setButton() to set a new one.
https://bugzilla.gnome.org/show_bug.cgi?id=788542
This D-Bus property was never been added here, which caused inconsistencies
under some scenarios (e.g. coming back from suspend) if some devices were
previously paired, since _sync() would then make the bluetooth menu visible
unconditially, because of the proxied property evaluating to 'false'.
Adding this to the D-Bus interface makes sure that it's no longer undefined
and returns the right value, fixing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=789110
Commit 28ca96064b added support for setting PopupImageMenuItem's icons
via GIcons as well as via strings. However as the check whether an object
implements the GIcon interface only works on GObjects, specifying an icon
name was broken. Fix that to actually allow both strings and GIcons.
https://bugzilla.gnome.org/show_bug.cgi?id=789018
The idea behind always showing the icon on the login screen is that
the users' needs aren't known at that point. However we can achieve
the same behavior by including the 'always-show-universal-access-status'
key in GDM's presets, so drop the special-case.
https://bugzilla.gnome.org/show_bug.cgi?id=788943
We were handling being initially headless by only setting the primary
and bottom monitor if there was any primary monitor, then checking the
primary monitor reference before making calls assuming there was any
monitors.
What we didn't do was unset the primary and bottom monitor when going
headless, meaning that temporarly disconnecting a monitor while having
windows open caused an assert to be triggered due to various code paths
taking the path assuming there are valid monitors.
Unsetting both the primary and bottom monitor when going headless avoids
the code paths in the same way as they were avoided when starting
headless.
https://bugzilla.gnome.org/show_bug.cgi?id=788607
We are already closing top bar menus on session mode changes, but
as this behavior makes sense for any other menus as well - dash
context menus or the background menu for instance - just generalize
the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=787676
Commit 1c7a3ee61b broke setting the initial key focus for default
buttons added via addButton(). Fix this by allowing the dialog class
to provide a different default widget to ModalDialog than the entire
dialog itself.
https://bugzilla.gnome.org/show_bug.cgi?id=788282
We don't use different hover- and focus indications for window previews,
so using keyboard navigation after hovering a clone often has surprising
results when the previous focus window wasn't the selected one. Address
this by simply moving the keyboard focus with the highlight.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
By default the focus chain uses the same order as the list returned
by clutter_actor_get_children(), which corresponds to the z-order.
This doesn't work well in the window picker, where clones follow
the stacking of windows to ensure a correct overview transition,
but previews are laid out purely based on space efficiency. As
a result, the order in which window previews are navigated when
tabbing around is essentially random. Fix this by providing a
focus chain implementation that is based on the visual layout
of the previews rather than the stacking.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
Don't assume there will always be a primary (logical) monitor, or any
(logical) monitor at all. This includes not allocating / layouting /
styling correctly when being headless.
The initial background loading will also be delayed until there are any
(logical) monitors connected.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
On the screen shield, the only possible interaction is lifting the
shield. The on-screen-keyboard is not useful for that, and the drag
gesture from the bottom may in fact conflict with dragging up the
shield, so disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=788339
As notification icons now align with the title, it makes sense for
them to follow the text size in case a text-scaling-factor other
than 1 is applied.
https://bugzilla.gnome.org/show_bug.cgi?id=788265
Not doing this will throw a backtrace when running on headless mode and
trying to show a notification, due to Main.layoutManager.primaryMonitor
being undefined, so it's better to return early.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When making any D-Bus call through the GDBus' proxy wrapper with an
invalid D-Bus object path, gnome-shell hangs.
Supposedly FdoApplicationProxy constructor should validate the passed
D-Bus object path and throw an error if the path is invalid. Since it
does not do that, we work it around by making sure that the deduced
D-Bus object path is valid or throw an exception if the path is not.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Some application IDs contain hyphens, which are not allowed in D-Bus object
paths, so we need to update the translation by converting them to something
that's a valid object path. This is consistent with what GApplication does.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Commit 289f982949 broke all remote providers when adding support for
non-auto-started search providers: Whether the provider should be
auto-started needs to be known in the constructor, so setting the
property on the constructed object doesn't work.
https://bugzilla.gnome.org/show_bug.cgi?id=787986
Ensure that key-above-tab for selecting window application is consistent
with the down key.
After focus an application in the switcher:
- if you press down, the window thumbnails are previewed, and first element
is selected
- if you press key-above-tab, the window thumbnails are previewed, however
the second element is directly selected.
Make both interactions always select the first element.
https://bugzilla.gnome.org/show_bug.cgi?id=786009
This would be used by search providers which only operate on data in the
running instance, such as the terminal's search provider which finds the
shell in the tab matching the search text.
https://bugzilla.gnome.org/show_bug.cgi?id=785380
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
It's not exactly clear what changed - gobject-introspection, gjs - but
the newly added gweather_condition_to_string_full() API no longer works
like it used to. The replacement code does look more idiomatic anyway,
so just fix the code without investigating the reason of the breakage.
https://bugzilla.gnome.org/show_bug.cgi?id=787423
If a source actor is set, use that for determining the arrow side (i.e.
whether the BoxPointer widget should expand in a certain direction).
This is better because it ensures that the popup is displayed on the
same monitor as the widget it originates from.
Without this, entering text with a vertically aligned input method
close to the bottom of a monitor would expand the BoxPointer downwards
on the monitor beneath it, instead of upwards, which is what one would
expect.
https://bugzilla.gnome.org/show_bug.cgi?id=786886
Now that full-sized window previews are allowed again it makes sense to
align the window previews with the pixel grid to prevent unscaled
windows from looking blurry in the overview.
In anticipation of showing the system actions in
the search results, it is fit to move action
specific code to its own module in order to
reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
The current behavior wasn't designed, but was introduced in commit
84efaac52b to work around technical limitations when we were still
using external tools like gnome-screensaver or gnome-session-quit
to handle the actions. Those limitations are long gone, so it makes
sense to make the actions consistent with the corresponding keyboard
shortcuts: Leave the overview when launching an application, and leave
it alone otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
Users already have to trust their OS, so asking whether an OS component
should be allowed to perform an OS operation is odd at best, if not
confusing. Account for this by allowing system components that require a
keyboard grab to work - namely Setting's keyboard shortcuts panel - to
do so without triggering the permissions dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=786146
This drops the requirement that SwitcherPopups need a modifier based
keybinding to work.
The existing behavior for modifier based keybindings is kept but if
the popup is triggered from a no modifiers keybinding, instead of
finishing when the modifier is released, we use a timer that
automatically finishes the popup. The timer is reset on every key
release to allow navigation to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=783550
GWeather now provides us with API to request strings that don't
use sentence capitalization, so we can use it for summaries that
don't start a sentence to make for more natural phrases.
https://bugzilla.gnome.org/show_bug.cgi?id=779873
As in commit b2b2f65 and furthermore it doesn't make much sense to
change the menu item according to the number of connections since all
connections here are of the same type.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
The new control-center shell split wifi configuration from the network
panel, and moved all other devices into a flat list. So instead of
manually spawning the app with the 'show-device' subcommand, we can
now simply launch the appropriate settings panel.
https://bugzilla.gnome.org/show_bug.cgi?id=786520
To make search more efficient, users don't need to move the actual
keyboard focus away from the search entry to activate the first
result. However the shift+f10 shortcut to pop up the context menu
via keyboard still acts on the actually focused widget, which is
the entry. It makes more sense to open the context menu of the
selected result instead, as that's what's highlighted and responds
to keyboard activation.
https://bugzilla.gnome.org/show_bug.cgi?id=675315
Otherwise the smaller icons will try to take too much space since the
texture rendering the icons will be scaled up on HiDPI displays according
to the scale factor, which will push the size of the StBin containing the
texture up, causing them to completely fill the folder's total space.
Explicitly setting the size of the StBin container in this case, in a
similar fashion to what we do when creating the empty placeholders (in
case where there are less than 4 apps in a folder), ensures that each
"cell" of the grid-like widget representing the folder does not take
too much space.
https://bugzilla.gnome.org/show_bug.cgi?id=786145
We need to consider the scaling factor in effect when updating the user's
avatar, and also make sure to update it as well whenever the scaling
factor changes.
https://bugzilla.gnome.org/show_bug.cgi?id=786120
The legacy tray introduced as part of the notification redesign in
3.16 was meant as a stop-gap solution to encourage applications to
move away from the concept of status icons, but it hasn't really
done anything except of getting in the way. Given that the large
majority of apps that still make use of status icons work perfectly
fine without them, we decided that it is time to drop this unloved
bit of UI altogether. Users who still want them (or use one of the
odd cases where an app really depends on the icon) can install one of
various extensions that are available, either based on the XEmbed
support that is still kept around or implementing the DBus-based
StatusNotifier spec.
https://bugzilla.gnome.org/show_bug.cgi?id=785956
Currently the chrome layer decides itself which events on the window
clone should show or hide the chrome, which makes it harder to extent.
Instead, move the decision to the window clone by letting it emit
show/hide-chrome events when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Previews are currently limited to at most 70% of the actual window
size. This was done to indicate more clearly that the overview is
active and the window cannot be interacted with. However since then
other indications like the vignette effect have been added, so
artificially limiting the preview size doesn't look necessary anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Now that only one window title is visible at any time, it no longer
matters if a title extends into other window previews, so we can
always show the full title.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
While the new title position gives the previews more space, they now
overlay the content which may hide valuable information. Address this
by only revealing the title as additional information on hover, like
we do for other auxiliary elements.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We consider the window previews the primary way to identify a window,
so it makes sense to give them as much space as possible. So in order
to not have title captions take up too much vertical space, overlay
them on top of the preview borders.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We currently expand the workspace switcher when workspaces are being
used, that is when there are any windows on a non-active workspace.
While this helps with the switcher's discoverability, it does eat into
the space available for window previews. By now the component should
be well established, so we can afford opting for space efficiency and
only expand the switcher while the user actually interacts with it.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
The overview's window picker is primarily about windows, and as the
previews that represent them are more effective the bigger they are,
it makes sense to scale down competing elements; start by reducing
the size of workspace thumbnails on the right ...
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Instead of potentially loading a background mid-way when it changes, and
loading it again for every file monitor event, leverage
CHANGES_DONE_HINT events, which allow us to ignore CREATED and CHANGED
signals from the file monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=747794
About every other situation can do with synchronizing keyboard visibility,
and keyboard layout changes are already handled internally in the Keyboard
object.
A downside of this approach is that once created, there will always be a
Keyboard instance and its full actor hierarchy. Seems reasonable to do that
since we can't tell it won't ever be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=785309
In case where a method- and property name overlap, using the method
is less unambiguous than I thought - mozjs52-based gjs will only see
the method, while mozjs38-based gjs will only see the property. We
are in luck though, and the real property name contains dashes that
allow us to refer to the property in a way that works for all gjs
versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
ClutterActor has both a has_pointer() method and a :has-pointer
property (that we represent as 'has_pointer'). So far gjs was
able to deal with the name overlap, but now trying to use the
property will instead test for the availability of the method.
Just avoid the conflict by switching to the method, which is
unambiguous.
https://bugzilla.gnome.org/show_bug.cgi?id=785090
We now cancel animations on override, however we also want to cancel
animations altogether on unmap (that is, when hiding the overview)
to avoid icons swarming into the void.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
Until now we were waiting the animation to complete to allow the user to
make a new animation. This could bring some problems and annoy nervous
users.
Instead of that, destroy clones on new animations triggers and
create a new animation with the new direction.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
The animation needs the icons' final positions, so we currently defer
it to a ::notify::allocation handler; however as starting the animation
during an allocation cycle would trigger a Clutter warning, it is
further deferred to a MetaLater. While this usually works, it is possible
that the allocation is already valid when we connect the signal, in which
case the animation is triggered at a later unexpected time. Switch to
a more robust ::paint handler instead, which also allows us to get rid
of the double-delay.
https://bugzilla.gnome.org/show_bug.cgi?id=736148
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
Symbols that are defined with 'let' are no longer visible outside
the module that defines them. To unbreak the code base, define all
non-private properties as global.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
The first time that the session is started, it can happen that the
AT SPI hasn't been correctly initialized, and this results in a crash
when attempting to register the caret or focus listeners.
In order to avoid this, these changes check the result of initializing
the AT SPI, to allow further attempts when it has failed.
https://bugzilla.gnome.org/show_bug.cgi?id=785047
Customization of keycombo actions for strips/rings was lost in the
porting to new incarnation of Wacom support.
The UI here is slightly different, instead of requiring the user to
rotate/swipe in each direction to map each keycombo, the UI will
navigate the user through edition of both options, first one, then
the other.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
Commit 39a840e2c3 added an additional parameter to shell_app_launch().
When adjusting callers, the parameter was also added accidentally to
calls of the confusingly similar g_app_info_launch() ...
Remove those to fix some warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The method currently catches errors that occur when calling the
extension's init() method, but throws itself an error if the
expected extension.js file is missing. The former is pointless
if we expect all callers to handle errors themselves anyway, and
we should avoid the latter if we don't - opt for the second option
and handle a missing extension.js file gracefully.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
While we catch errors that occur when calling init(), enable() or
disable(), the import itself can throw an exception, for instance
if the extension imports an unavailable typelib or tries to draw
in a conflicting library.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Both reloadExtensions() and enableExtensions() are already expected
to catch extension errors. If they don't, this is the bug that
should be fixed instead of catching unhandled exceptions in the
caller.
This reverts commit ff425d1db7.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Those will go away when we port authentication prompts to the new
MessageDialogContent widget, so pick the style classes from there
and adjust individual properties with more specific rules to re-
produce the existing style.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
A lot of our modal dialogs share a similar structure:
[Icon] Some title
Maybe a subtitle
And sometimes even a body for stuff like
longer descriptions.
A dedicated widget with a common style will allow us to significantly
reduce duplication of both code and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
This is the basic dialog actor implementation, which will allow us to
use the same implementation on the session-global modal dialogs. The
ModalDialog class now uses it underneath, and so do all users of it.
https://bugzilla.gnome.org/show_bug.cgi?id=762083
let trackChrome accept actors that are not children of chrome actors.
this will be useful for the MetaCloseDialog in gnome-shell, which
is already included in the MetaWindowGroup, but needs to be tracked
as chrome for the dialog to receive pointer events on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=762083
The actor allocation will be invalid on CLUTTER_TOUCH_BEGIN, because
it comes together with a CLUTTER_ENTER event that will recalculate
styles, and queue a relayout in result.
The net result is that on CLUTTER_TOUCH_BEGIN, the relayout has been
already queued, so the slider width comes up as 0, and the value ends
up as 1. Later touch events already happen on a validated actor, so
it is corrected. Still, not fun when modifying the volume slider on a
touchscreen.
Having descriptions with multiple lines will clutter
the view and make it more confusing for the user. Apart
from that, it also makes the search result a lot bigger,
potentially losing general vertical alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The classes extending the SearchResult can now connect
to the 'terms-changed' signal emitted by the SearchResult
class. This signal enables each object to update its
internal description in order to apply the bold style
onto strings that match the search terms.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to prepare for applying the bold style to the part
of the description that matches the search terms, we need
to listen for the signal that announces the fact that the
search terms have changed. Given the fact that the
SearchResults class is aware of the changes regarding the
search terms, the classes that extent SearchResult need
to have a reference to it in order to listen for the
to-be-implemented 'terms-changed' signal.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
Since results are now much more concise and take up less
space, we can use the 'saved' space to provide the user
with more search results for each provider.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The current separator uses a gradient effect as a separator
between search results. As the mockups suggest, the gradient
separator is no longer needed, in favor of a more simple one,
which is a thin semitransparent line.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to match the current mockups, the providerIcon
class needed to include both the name of the provider
and the label that informs the user about how many more
search results are available for that specific provider.
The latter replaces the plus sign icon that has been
used so far.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to make gnome-shell search functionality fit on
smaller screens, like those of devices, search results
need to take advantage of more horizontal space so that
any extra space can be used efficiently.
In order to do so, change the layout of the ListSearchResult
class from a vertical one, to a horizontal one and also
decrease the padding of the list-search-result-content css
class.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
If the padOsd is given a nonexistent ring/strip, things would fail
badly later when trying to paint a 0x0 StLabel. Just avoid creating
more ring/strip labels than those known by libwacom.
This is unlikely to happen, but seems better to protect against it.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
The porthole will not be destroyed when the scale factor changed.
That makes workspace thumbnail porthole still wrong size in the first
seeing after the scale factor changed.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
PopupMenu needs special-treatment of certain types of menu items,
which it determines via children's _delegate property. However as
the calendar drop-down is very unmenu-ish, we use regular actors
rather than PopupMenuItems and the missing _delegate property
triggers a warning. Just add it as the bare minimum to make
PopupMenu happy.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The destroy effect currently relies on a monkey-patched property
added from the map effect. However on X11 it is possible that we
did no map animation for a window that is destroyed when the shell
was restarted or had taken over from another WM. Just use the real
MetaWindow property to avoid a warning in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
It's possible for updateRegions() to be called before monitors have
been properly initialized. Instead of throwing an error in that case,
just skip the strut computation (that doesn't make sense anyway without
a monitor).
https://bugzilla.gnome.org/show_bug.cgi?id=781471
findMonitorForActor() may be called before the layoutManager gets
to initialize monitors, so make sure the monitor index is in range
to avoid a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We need to track the open-status of indicator menus, but don't want
to hook up signals more than once, so we check for the handler ID
we store on the object. As the property is only defined once we did
set up the signal connection, this check now logs a warning. We
can avoid it by checking for the existence of the property rather
than a particular value.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
To avoid recreating the app menu unnecessarily, the panel checks
whether the menu's current actionGroup already matches the target
one. However as the menu's actionGroup property is currently private,
the test always fails, whoops.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We currently use "array[index]" to test whether an array has an
element at index before using it. However nowadays gjs warns about
accessing non-existent array elements, so the test itself already
produces a warning. Avoid this by checking the array length before
using an index to access an element.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
It is possible to use the scroll wheel to adjust the volume without
opening the system menu, but there is no feedback other than the
icon itself in that case. To provide a less coarse indication for
the volume level, display the OSD window when adjusting the volume
while the slider isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=781028
Since commit 2c070d38, we add a ClickAction to the visible AltSwitcher
button to track long-presses. As a result, we now have two components
that will grab and ungrab the pointer for the button, so to make sure
we don't end up with a stuck grab, we need to release the second's
component grab when the first activates.
Currently we only drop the StButton grab on long-press, we also need
to cancel any initiated long-press on click.
https://bugzilla.gnome.org/show_bug.cgi?id=781738
We currently assume that window state changes are accompanied by an
allocation change (triggered for example by the minimize animation).
However this misses the case where a window actor is simply hidden
without any transition, as is the case with the 'show-desktop' action
for instance, so start tracking plain visibility changes as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783975
There were some source IDs that were not being reset to zero when
removing the associated sources, resulting on some critical errors
being dumped when _realRecalculateWindowPositions() got called
after that point, via _delayedWindowRepositioning().
This effect will only be created when the StScrollView actor has either
a non-zero vertical or horizontal fade offset defined, so we need to
add a null-check in these two cases before assuming it's there.
https://bugzilla.gnome.org/show_bug.cgi?id=783823
The .solid style isn't supposed to apply for modes that don't support
windows, but for this to work we have to update the style on session
mode changes.
https://bugzilla.gnome.org/show_bug.cgi?id=783202
Commit b929320d4 added a toolbar item to force garbage collection,
however it won't be visible for most users, as it uses a non-standard
legacy icon name (the default icon theme dropped it as far back as 2009).
https://bugzilla.gnome.org/show_bug.cgi?id=782982
The fullscreen animation code is now generic enough to handle any
size change animations, so stop limiting it to (un)fullscreen to
get animations on (un)maximize as well.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Currently, the translation values are set with the assumption that
one of the actors represents a fullscreen window. In order to
generalize it for any size change transition, we can simply swap
the monitor rect with the source or target rect as appropriate,
and translate the actor from the target to the source position by
subtracting the former and adding the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
Since there is already targetRect that represents where the
window is going to move, rename oldRect to sourceRect to
represent from where the window is moving.
https://bugzilla.gnome.org/show_bug.cgi?id=766685
If the popup happens to be mapped beneath the pointer, mutter will now
emit an implicit enter notify event (i.e. not caused by pointer motion).
In this case the switcherPopup still goes and selects the item, which
results in too sensitive alt-tab menus if the pointer happens to be in
the wrong place.
Make highlighting rely on motion events instead, so it always involves
user interaction when triggered by the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.
https://bugzilla.gnome.org/show_bug.cgi?id=747163
And merge with the "internal" show/hide() ones. Those functions don't
proxy dbus method calls anymore, so it makes no sense to expose these.
Also, the timestamp is no longer needed as there is a single source for
these events.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
The caribou daemon only gives us focus tracking, which is almost 1:1 with
our own FocusCaretTracker implementation. This means we can entirely
replace the Caribou daemon inside gnome-shell, reducing the Caribou
dependency to just libcaribou, and more specifically the
CaribouKeyboardModel we pull the keyboard models from.
As we still need underneath a CaribouDisplayAdapter to drive the keyboard,
reuse the wayland one, which has been renamed to make it look generic, plus
it will use the virtual input device API from mutter/clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=777342
Some search providers such as GNOME Characters want to copy search
results to clipboard. However, on Wayland, clipboards are only
accessible from applications that have a visible surface on display.
This patch allows a search provider to request the shell to copy a
search result to clipboard when 'clipboardText' is included in the meta
of the result.
https://bugzilla.gnome.org/show_bug.cgi?id=775099
We are moving the icon to be added before the text instead of after,
which is consistent with other menu items in other popup menus, such
as the ones in the system indicator's popup menu.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
This allows passing an optional icon parameter to addAction()
so that a PopupImageMenuItem instance is created instead of a
PopupMenuItem if an icon is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Add an extra check to setIcon() so that either a GIcon or an string
with the icon's name is handlded, so that we can create menu items
in different ways (e.g. by passing a GIcon created from a resource).
https://bugzilla.gnome.org/show_bug.cgi?id=782166
Some extensions out there may fail to reload. When that happens,
we need to catch any exceptions so that we don't leave things in
a broken state that could lead to leaving extensions enabled in
the screen shield.
https://bugzilla.gnome.org/show_bug.cgi?id=781728
Recently Music gained a flatpak manifest inside the repo in bug 779905.
However that requires the desktop file to be properly named like
DBUS addresses are.
This patch renames the old Music desktop file to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=780157
Add a new D-Bus method for setting the monitor labels. This new method
takes connector names instead of output ids for associating with actual
monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Since the workarea and margins are both in pysical pixels dimensions (we
fetch margins from Clutter, not from the theme), but the CSS expects
logical (scaled) pixels, unless we consider the scale factor when
setting max-height, it won't work on a HiDpi display.
This fixes missing scrollbars when the calendar popup is full on HiDpi
displays.
https://bugzilla.gnome.org/show_bug.cgi?id=753305
Generalizing menu toggling via keyboard in commit 1d58ea25ab
fixed keynav in many places, but it turns out that it also adds
unexpected interactions in some cases where the source is not
button-like, as for example the entry context menus provided by
ShellEntry. Commit e33c68a415 fixed one case, however it is still
possible for plain enter/space to unexpectedly trigger the menu
if the entry itself doesn't consume the event, which is the case
when ClutterText:editable is false. However for a general fix, it
makes more sense to consider the source actor's :reactive property
and disable toggling menus via keyboard when they cannot be toggled
by pointer either - expecting non-editable entries to be non-reactive
as well seems like a reasonable assumption, and indeed all our code
follows that pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=758873
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
When using the 'disable-lock-screen' setting to lock down the screen
lock, the expectation is that users cannot lock the screen. However
as it turns out, all the setting currently does is hiding the lock
button in the system menu and making the lock settings in the privacy
panel inactive. That means that if the 'lock-screen-enabled' setting
isn't disabled and locked down as well, we will just continue to
lock the screen on inactivity - not to mention the keyboard shortcut
that isn't subject to that setting anyway.
Instead of expecting administrators to hunt down every possible way
of locking the screen and disabling it individually, we can easily
handle all cases by refusing to lock the screen when disabled by the
lockdown settings.
https://bugzilla.gnome.org/show_bug.cgi?id=780212
Dragging and dropping app icons is expected to work anywhere over a
workspace, however overlaid elements are added to a separate hierarchy
and can thus block valid drop targets. This wasn't much of an issue
while we had just the window title, but since the addition of the
focus border, drops on window previews stopped working entirely.
Fix this by hiding all non-reactive overlay elements from picks.
https://bugzilla.gnome.org/show_bug.cgi?id=737166
Currently when the wifi selection dialog is open when the screen lock is
activated, the dialog remains visible above the shield. This is clearly
broken, so close the dialog automatically on session mode changes if the
mode doesn't allow settings (as changing the access point is arguably a
user setting).
https://bugzilla.gnome.org/show_bug.cgi?id=780054
The critical hint is meant to be used for notifications that must not
be missed - running out of battery being the prime example - so it
makes sense to ignore the policy in that case and make sure to always
show them to the user. This is consistent with blocking normal
notifications while showing a fullscreen window, but letting critical
ones through.
https://bugzilla.gnome.org/show_bug.cgi?id=779974
Whenever there's more than one pad in the same group (eg. Wacom ExpressKey
Remotes), show a popdown menu to allow configuring those extra pads.
Devices are hot-pluggable, so the popdown menu will update its state
whenever pads are added/removed.
Also, allow to quickly change between pads by switching to its OSD by
just interacting with them. Always given they are in the same group.
https://bugzilla.gnome.org/show_bug.cgi?id=779986
Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
For most notifications, banners are suppressed while the monitor
that is used to display banners is in fullscreen. With the old
message tray at the bottom, this used to be the bottom-most monitor,
but nowadays it's always the primary one, so update the corresponding
code to use the correct monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779819
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
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
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
Media notifications currently always show the forward and backward
buttons as clickable, regardless of whether the corresponding action
is available or not. Media players usually address this by rendering
controls insensitive in this case, so do the same here.
https://bugzilla.gnome.org/show_bug.cgi?id=773884
Without the boxy background, event messages look a bit plain and
unaligned with other messages. Adding an icon addresses this,
however as repeating the same icon over and over again in case of
many events would be rather noisy, only show it for the top event
as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Update the notification style according to the latest mockups:
- make notification icons smaller and prefer symbolic variants
- remove background box when not hovered/focused
- increase spacing between elements
- use normal text sizes
https://bugzilla.gnome.org/show_bug.cgi?id=775763
For notifications in the message list, it is usually less relevant
when exactly it occurred, but how long ago. So rather than showing
the exact time and expecting the user to figuring out the timespan
themselves, change the format to something human readable.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Currently the secondary actor (if set) and the close button are
exclusive, that is the latter replaces the former on hover. As
the swapping feels rather busy and there's no real reason both
cannot be shown at the same time, keep the secondary actor always
visible.
A welcome side effect is that it no longer needs to be placed at
the end, so we can move the notification timestamp right next to
the corresponding title.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The section titles usually don't provide a lot of value - messages
themselves are usually pretty unambiguous about their type, and
having a hidden shortcut to some settings panel or application isn't
essential either - except when showing the selected date when browsing
other days, as it adds context to the listed events. Based on that,
remove the section title as a general MessageListSection feature and
move it into the EventsSection, where we only show it when it is useful.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
We will eventually remove section titles from the message list to
reduce visual noise and give the actual information provided by
the messages more space. So in order to not lose the ability to
mass-dismiss messages, the latest mockups spot a "Clear All" button
at the bottom - implement that.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The latest mockups contain a button to clear all sections at once.
As some elements cannot be cleared, we need to provide that information
to avoid offering an action that has no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Similar to the Clocks integration we've had in the date+time drop-down for
a while, the designs have called for a similar section that integrates
GNOME weather as well. Use the WeatherClient added in the previous commit
to implement that section and add it to the popover.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In order to avoid distracting popup size changes while browsing
other dates, we freeze the size to the last size request. However
in case of more complex size negotiations - wrapping or ellipsizing
labels, scrollable elements etc. - there's a chance of stray calls
to get_preferred_width/height() that are not used for the actual
allocation. If such a call happens to be the last size request
before the layout is frozen, the saved size will be wrong. To fix
this, save the allocated size rather than the requested one.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
We want the width of the calendar column to be determined by the
calendar, other elements should adjust their allocation accordingly.
However neither ellipsization nor wrapping will kick in unless the
parent's width is restricted, so use a small custom layout manager
that enforces the desired behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
