Whether people love or hate the hot corner depends in large extents
on hardware sensitivity and habits, which is hard to get right
universally. So bite the bullet and support an option to enable or
disable hot corners ...
https://bugzilla.gnome.org/show_bug.cgi?id=688320
The top_window_group is used for windows like popup menus, which should
appear above shell chrome like the panel.
Since we want important actors such as the screen keyboard or modal
dialogs to be shown above those windows, add their actors after adding
global.top_window_group to this.uiGroup and provide a new function
addTopChrome() to add important chrome above the top_window_group.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/917https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/358
The bind constraint that replaced the Shell.GenericContainer in commit
f4682748fa is subtly different from the previous code:
It forces the actor to have the same size as the stage, rather than just
requesting that size.
This breaks the magnifier which relies on the UI being able to be bigger
than the display size. Fix by going back to using a custom actor.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/646
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When a fullscreen application is focused,
toggling the overview via hot-corner is disabled,
even when the overview is currently visible.
This only makes sense, when the overview is
hidden to not to disturb the behaviour of the
fullscreen application, but leaves an
inconsistency when the overview is visible since
it should work there like when a non-fullscreen-
application is focused.
So, always allow hiding the overview using the
hot corner when the overview is visible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/429
LayoutManager is currently a pure JavaScript class that
relies on the rudimentary Signals.addSignalMethods() to
handle signals. This is an inefficient implementation of
one of the most central classes in GNOME Shell.
In addition to removing Shell.GenericContainer, then,
turn LayoutManager into a proper GObject.Object subclass.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
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
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
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
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
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
Commit c39ffa111 moved the signal handling from the controls- to the
background-group to enable scrolling on non-primary monitors.
However this broke scrolling on reactive overview elements as the
workspace switcher, as they're not descendants of the background.
To fix, move scroll-event handling to the overview group itself,
which is the common ancestor of all overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=768316
When we restart, we need to update the struts for the screen before
we enter the main loop, or maximized windows will get resized to the
size of the screen without struts, then resized back.
A workaround is needed for a Clutter bug that occurs when we get
the size of an actor before the first paint of the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=761566
When chrome is added with the trackFullscreen parameter, the actor's
visibility will be updated automatically whenever its monitor's
fullscreen state changes. However as we currently ignore the fullscreen
state at the time the chrome is added, the initial visibility may well
be incorrect - fix this by updating the initial visibility as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=749383
For barriers like the hot corner which are made up of multiple axis
barriers, make sure that all the barriers have been left before
resetting the barrier.
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
Since commit e189a34, the trayBox uses a Contraint to cover the primary
monitor's work area. This allows banners to be clipped so they don't
leak into monitors above the primary one during animations. However even
without being reactive, the trayBox now interferes with operations like
Looking Glass' object picker and overview DND.
With the trayBox no longer being positioned manually, there's no strong
reason to keep it in LayoutManager, and handling it in MessageTray allows
to hide the actor while no banner is showing, which helps with the issue
outlined above.
https://bugzilla.gnome.org/show_bug.cgi?id=744912
The panel is not visible when in fullscreen, but critical notifications
may still be shown - having them pop out from where the panel would be
looks unpolished, so adjust the trayBox accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was removed as actors that should not affect the input
region can simply be added to the uiGroup instead. However
the property is useful to add non-reactive chrome, but then
use trackChrome() to add a child to the input region.
This reverts commit e62d22a50e.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Occasionally it makes sense to constrain to a monitor's work-area
rather than the entire monitor, so implement that behavior and add
a property to turn it on.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Don't assume struts are on the primary monitor while computing
the strut side. Instead, find the first monitor that overlaps the
strut and compute the strut side using it.
https://bugzilla.gnome.org/show_bug.cgi?id=744183
Since the background rework, SystemBackground is no longer a transparent
actor that you have to stack on top of a solid background, it is an
opaque actor. Fix the color of the background actor, and remove places
where we were setting the background color underneath the system background
and expecting blending - in particular, we can always set no_clear_hint
on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=738652
When monitors change, the previous index might not mean the same
physical monitor anymore, in fact, it might become invalid. In the
latter case, we'll actually get a JS error when accessing
this.keyboardMonitor in _updateKeyboardBox() . To avoid this, let's
just always reset the OSK to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=738536
If we have a modal, the stage's input region doesn't really matter --
all events go to us anyway. To avoid doing extra work doing animations
when we have a modal, like menus, the overview, and the message tray,
just fizzle out all updates.
To make sure we catch updates, update the input region whenever we end a
modal.
https://bugzilla.gnome.org/show_bug.cgi?id=737001
