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.
While can_open_new_window() uses some elaborate heuristics to predict
whether an application can open multiple windows, open_new_window()
will always simply relaunch the application. This is often the best
we can do, but when an application provides a "new-window" action in
its .desktop file or on the bus, it is much more likely to work as
expected than blindly activating the app and hoping for a particular
behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=756844
Graphical applications like GIMP or GIMP allow picking colors from
any location on-screen. In order to keep supporting this feature
on wayland and in sandboxed apps, we will expose an appropriate
method in the Screenshot interface, so first add a corresponding
method to ShellScreenshot.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/286
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.
When in lockscreen mode there's no point of resetting the auth login as there's
no welcome screen, and that would just cause the UI to freeze, with no reason.
This could have been useful if we were stopping the user to login for a given
time after ALLOWED_FAILURES attempts, but this is not the case yet.
When we get a reset signal the preemptiveAnswer should be also unset or it will
be used next time the user authPrompt will be activated, even without any further
user interaction.
Fixes#311
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
Some systems define it to /usr/lib64 on 64-bit systems, which is not
where systemd looks for unit files. Just hardcode 'lib' in the install
prefix until we get to use the pkg-config file.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/424
The input method may hint that certain keycodes should be pressed/released
besides the textual information in ::commit. An example is hitting space
in some IMs to commit text, where both ::commit happens, and an space is
visibly inserted. In order to handle this properly, we must honor
::forward-key-press.
In order to cater for the case that a keypress is forwarded while handling
that same keypress in a physical keyboard, check the current event being
handled and just forward it as-is if it matches. This is necessary to
prevent state from being doubly set, and the second event silenced away.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/275Closes: #275
So that we can be started by systemd --user, instead of gnome-session.
There are three units:
- gnome-shell.service: Start gnome-shell itself.
- gnome-shell-x11.target, gnome-shell-wayland.target: Sync points for
units that need to care if x11 or wayland is in use.
gnome-settings-daemon will use these, for example.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/138
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
All adjustment setter functions take good care of avoiding emission of
notify:: when it's not needed. The set_property() implementation already
calls into the setter functions, so mark the properties as EXPLICITY_NOTIFY
in order to optimize notify:: emission away through g_object_set (rather
common from JS code).
The actor allocation doesn't change per-se, but apply_transform()
will practically transform it. In order to have the paint volume
update accordingly, queue a relayout.
The default get_paint_volume() implementation will do the union
of children, and the child ClutterText paint volume may expand
beyond StEntry size when text overflows.
We actually want all content to be clipped to the StEntry, so
implement get_paint_volume() and tell it so.
And constrain it in StScrollView instead (instead of falling back to an
infinite paint volume, as the actor as paint/pick impls, but no
corresponding get_paint_volume one).
Fixes artifacts with the AppView (and possibly other places) when paint
volumes are aggressively cached.
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
