The settings action button in the system menu simply launches
gnome-control-center, so we want its icon (and accessible name)
to always match the app. So instead of keeping the button in-sync
with Settings, just look up that information from the app itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
We can simply request the symbolic variant from CSS so that we don't
have to append '-symbolic' to all the names. This will always make
it easier to pick up that information from external sources (like
.desktop files).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
Commit e5c95b910d refactored the workspace animation to also handle
animations that involve all surrounding workspaces, but due to an
ill-advised review comment (guess whose) it broke the animation
for non-neighboring workspaces.
Update the code to handle correctly whether in a given direction:
- we have the target workspace of a given index
- we have a neighboring workspace
- we don't need to animate anything
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/182
Add a debug command (to be executed manually via Alt+F2) to check
that all of gnome-shell's file descriptors have the CLOEXEC flag set.
This is important so that internal file descriptors do not get passed
to apps when they are launched.
It prints a warning message for every fd that does not have the flag set.
fdwalk() is used from the standard library if available (it is not
available in glibc), otherwise we use the same implementation as glib
has internally.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
When 4fg swipe motion happens, set up early the workspace switching
animation with all surrounding workspaces. This allows us to move
all content back and forth in any direction. This works on both
touchcreens and touchpads.
When the gesture is activated, the same data is reused to follow
up with the tween animation.
The threshold has been also doubled, it was fairly small to start
with, and feels better now that workspaces stick to fingers.
https://bugzilla.gnome.org/show_bug.cgi?id=788994
Besides the separation into distinct functions, the stored data has
been made able to generically store windows from all surrounding
workspaces. All while keeping a special mode to animate between two
workspaces (The usual till now), this is the only mode exercised so
far.
In order to ease animations, all window groups are now children of
a common container, which is then animated.
A custom callback type is more convenient, but only as long as no
other callback type is required. We are about to add functionality
that does not return the filename to a screenshot saved on disk, so
prepare for that by moving to GIO's generic async callback pattern.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/286
Fullscreen windows cannot be restored by touch device users unless the
application adds support for it.
As it is unlikely to change all application lets introduce a top edge
drag gesture which unmakes fullscreen windows.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/123
Make the indicator for active remote access use the warning color, to
indicate the severity of allowing remote access.
This only makes the indicator icon orange; the icon in the system menu
is still white.
Add an indicator for when there is something access the display server
remotely. This could be 1) remote desktop, 2) screen cast or 3) remote
control, but all effectively applications using
org.freedesktop.portal.ScreenCast or org.gnome.portal.RemoteDesktop as
well as gnome-remote-desktop using the corresponding org.gnome.Mutter
APIs directly.
As it is now, it'll simply show a single icon for when anything is
having an active session, and a single action "Turn off" that'll close
every active session.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/160
If we're started by systemd, we won't be in the user's display session.
However, this is still the session that will get locked & unlocked. Ask
logind what the 'display' or 'greeter' session is, and watch for the
Unlock signal for that session to know when to unlock.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/137
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
Maximized and tiled windows can be restored with a drag gesture,
not only from their titlebars, but also from any non-reactive
parts of the top bar above the window. Currently this only works
for actual pointer devices, extend the behavior to handle touch
as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/112
If the Escape key is used for a window/app cycler/switcher shortcut
(such as "Switch windows directly"), then there is no way to cancel
the switching/cycling operation with the keyboard.
This change allows cancelling such an operation by pressing the Tab
key, but only if Tab is not already being used by the current
switcher/cycler shortcut.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/315
Key events involved in a keyboard shortcut are not completely consumed by
Mutter. That means that if the popupMenu is bound to a shortcut (e.g.
Alt<Space>) and the user keeps the keys pressed, the same key-event will be
delivered to the popupMenu. We can workaround this issue filtering out all the
events where a a modifier is down (except capslock).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/372
Destroying and recreating the entire events list on every change is not only
wasteful, it also breaks the clear functionality as messages scheduled for
removal are replaced with "new" messages after the first message has been
removed.
Address both issues by keeping track of all messages and re-use them
whenever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/325
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.
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
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
This may be the case where keyboardIndex is -1, which may be the
case where either the keyboard monitor hasn't been set yet, or
the keyboard is being unmanaged and meta_window_get_monitor
returns -1
https://bugzilla.gnome.org/show_bug.cgi?id=788882
When middle-clicking an app icon on the Dash, it will always try to open
a new window of that app, even if the app doesn't support multiple
windows. Meanwhile, Ctrl+click on an app will only open a new window if
the app allows it.
This change prevents middle-clicks on app icons from opening new windows
for apps without multi-window support.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/316
When the actor that has the key focus is destroyed, Clutter moves
the focus to the stage. In case the destroyed actor was inside a
ModalDialog, this breaks any keyboard interaction: keynav is broken
because the stage isn't in any focus chain, and access keys like
Escape because they are handled on the dialog's parent.
The only dialog that may destroy a child without recreating the dialog
buttons (and thus moving the key focus there) is the WirelessDialog,
fix it by keeping the key focus within the dialog when removing networks
from the list.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/76
Just like we did for the window list in app icons' context menu,
provide a fallback for window captions in the window picker rather
than showing blank items to the user.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The app icon's context menu contains a list of open windows,
identified by their title. As we currently don't handle the
case where the app didn't set a title, we end up with empty
menu items which looks clearly broken. Fall back to the app's
name in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The close dialog for non-responding windows is closed automatically
when we detect that the window is responding again. However as we
currently only ping the window in response to certain user actions
(like focusing the window or opening the window menu), this can
easily go undetected.
Address this by periodically pinging the window while the close
dialog is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
The dialog won't be visible when unredirection is in place (for example
while a fullscreen window is focused), so disable unredirection while
the dialog is up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
Similar to what it's done when the main connection changes, we need
to make sure that the icon in the panel gets updated before calling
_syncConnectivity(), so that the icon gets always updated if needed,
regardless of whether there's an active connection or not.
This is needed because there's at least one case when an icon should
be shown when the computer is not connected to any network: when a
hotspot has been enabled, which can be useful even if there's not
an internet connection to share (e.g. to easily allow connecting
other devices to the computer.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/214
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
Commit f285f2c6 changed Scripting.createTestWindow() to accept a parameter
object instead of a parameter list but forgot to remove the width and height
arguments. This breaks the "core" test as all windows are created with default
settings.
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
If we get an error during device enrollment, the message might be
prefixed to indicate that the error came from the remote peer. We
are presenting that message to the user so strip that prefix away
if it was there.
The devices emitted (device, error) while the connected handler
was expecting (error, device). The former is more consistent
with the rest of the code (so change it to device, error).
Modes, extensions and other GNOME Shell assets are searched in appropriate
subdirectories of each directory in XDG_DATA_DIRS, falling back
to global.datadir.
However, this isn't the case for themes, which are currently always expected
in global.datadir, even when referenced by a mode in a different XDG_DATA_DIR.
The fix is to have the theme finding pattern follow the same logic as other
elements.
Fixes#167.
The HIG discourages the use of icons in menus except for "noun" items
(files, bookmarks, ...). While those should be rarely used in the
application menu, it still makes sense to support them in the few
cases where they are used.
https://bugzilla.gnome.org/show_bug.cgi?id=760985
Otherwise it happens that porthole is computed again after that the
overlay is hidden (triggered by a layout reallocation) and thus not
regenerated again afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=792687
Since commit 78a92fb6be we no longer pop up authentication dialogs
on the lock screen, however any dialog that is already open at that
time remains open. This is unexpected, so hide the dialog until
the screen is unlocked again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/166
Since commit 1939e22c22, we move the keyboard focus with the hover
highlight. However while this makes sense when interacting with
the window picker, it interferes with keyboard navigation of other
components like dash or top bar. Address this by only moving the
focus when the previous focus was already inside the window picker
or unset.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/50
The original UTC support in GWeather piggy-backed on the existing API, but
as "country" or "city" don't make sense in the context of UTC or AoE, the
concept of "named timezones" was introduced. Handle those explicitly to get
back labels for those locations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/150
We don't toggle the overview if the request happens too close to the
last activation, to filter out double-clicks or activation by both
the hot corner and a click. However as the check is based on the
real time, the check breaks if the system clock moves backwards and
the last activations appears to be in the future. Fix this by using
monotonic time which is guaranteed to only move forward.
https://bugzilla.gnome.org/show_bug.cgi?id=763886
While polkit requests *should* be the result of a user action, that's
not always the case in practice and authentication dialogs can pop up
out of nowhere at any time. That's always annoying, but particularly
bad on the lock screen. If we disabled the polkit component altogether,
the fallback GTK-based agent would kick in, so instead handle the case
explicitly and postpone showing the dialog until the session is unlocked.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/179
boltd 0.2 gained a property that indicates if it is authorizing
devices or not. If it indeed is not authorizing then we wont
try to enroll new devices because that would otherwise lead to
and error.
When we move keyboard focus to the search entry, we replay the key press
that triggered the move to the entry using ClutterActor's event() method.
Since commit 3b293e91e we specify that the event is in the capture phase
to make it work with StIMText, but now that commit 83accce24 removed it,
we have to return to the expected non-capture flag that matches the orig-
inal event to unbreak find-as-you-type functionality.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Find-as-you type was never automatically handled by StIMText, but
by the existing stage key-press handler. The functionality broke
for a different reason, we will fix it after reverting the recent
captured-event changes.
This reverts commits bc4462cd0c and e4ee944d8d.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/72
Since commit c4f2bb5f, close buttons are hidden by making them fully
transparent rather than setting their visibility to false to keep
the overall message layout stable. As a result, the buttons now work
even when invisible, which is clearly unexpected - fix this by updating
the reactive property appropriately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/66
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.
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
