Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
We call global.sync_pointer() on MetaScreen::restack as a hack to try
to fix up the hover state after a pointer grab. Previously we were
doing this in chrome.js, since there was already a ::restack handler
there anyway, but this isn't really related to the chrome at all, so
move it to main.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
Using the list of stylesheets loaded with st_theme_load_stylesheet(),
one can build an StTheme that is completely identical to the previous
one, except for one property (application-stylesheet).
This allows rt and the user-theme extension to work while respecting
the theming of other extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=650971
Move some more environment-initializationy stuff from main.js to
environment.js, and be more careful about not importing shell JS
modules until after the environment has been fully patched.
Change gnome-shell-plugin to call Environment.init() before
Main.start(); this means that Environment.init() now runs before any
shell JS modules (besides environment itself) have been imported.
Make run-js-test create a ShellGlobal and use its js_context, so that
the shell_global_set_property_mutable() stuff in Environment.init()
will work correctly in tests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=649203
Since the hotcorner is a reactive actor, and it is over the Activities
button, hovering on it results in a leave-event for the button.
This is not noticeable when opening the overview, as the button is
correctly prelighted, but it is when closing, if you keep the mouse
near the hot corner, as the button is kept in normal state, despite
the mouse being over it.
https://bugzilla.gnome.org/show_bug.cgi?id=645751
Inside the Shell, all the UI (including chrome, the overview, and
the actual windows) is not a child of the stage but of a special
ClutterGroup, which is cloned inside the magnifier.
Add function for setting this special actor so that actors added by
St are visible in the magnifier. Nothing yet uses this, but the
tooltip will soon.
https://bugzilla.gnome.org/show_bug.cgi?id=635100
Main._nWorkspacesChanged was racing with Main._checkWorkspaces.
If _checkWorkspaces won the race, _workspaces was uninitialized.
Because of this, _checkWorkspaces only noticed workspaces
with windows on them, leading it to believe the last workspace wasn't
empty, and added a new, empty workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=645343
To avoid having hot corners that accidentally trigger when e.g. trying
to hit the panel on the primary monitor we add hot corners only to
monitors that are "naturally" top left (top right for RTL).
For instance, we'd like a hot corner here:
corner -> +-------------
| |
+---------+ |
|=========| |
| | |
| | |
| | |
+---------+------------+
But not here:
unexpected hot corner
↓
+---------+-------+
|=========| |
| | |
| +-------+
+---------+
https://bugzilla.gnome.org/show_bug.cgi?id=645116
If a workspace becomes empty due to a window changing to/from the
primary monitor, but not changing its original workspace then we
were not noticing this. This can happen for instance if you drag
a thumbnail window to a non-primary window.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Move the "system notification error" handling out of
util.js, and add it to ShellGlobal so we can start
calling it from across the codebase better (including
C).
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Don't enter the overview at startup, or when we we remove the
last window on the first workspace, but only when we remove a
workspace and there are windows on the other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=644541
When closing a workspace due to the last window on that workspace
closing, switch to the overview and show the always empty workspace
rather then just going to the adjacent workspace.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
Fix the "panel" icon to be symbolic. Make the overview parts only show
up when in the overview, and the non-overview parts (eg, the Desktop
window, if there is one) only show up when not in the overview. Sort
the different items consistently with their locations on the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
We need to do the initial relayout before we start up the startup
animation, and the startup animation can't hardcode the position
of the panel to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
1. disconnect destroy signals in popModal (actors can have great lifetime and then pushed again)
2. incorrect pushModal/popModal pair in overview
https://bugzilla.gnome.org/show_bug.cgi?id=64078
Currently we remove a workspace when last window on that workspace closes,
which turned out to be too agressive as some apps open either a splashscreen
or a "I have crashed last time" dialog at startup.
Try to detect such apps and give them a chance to open their "real window(s)"
on the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
Unfortunately the evolution-data-server client-side libraries seem to
block the calling thread. This is a major problem as we must never
ever block the main thread (doing so causes animations to flicker
etc.). In the worst case, this problem causes login to hang (without
falling back to fall-back mode) and in the best case it slows down
login until a network connection is acquired.
Additionally, in order to sanely use these evolution-data-server
libraries, GConf has to be involved and GConf is not thread-safe. So
it's not really feasible just moving the code to a separate
thread. Therefore, move all calendar IO out of process and use a
simple (and private) D-Bus interface for the shell to communicate with
the out-of-process helper.
For simplification, remove existing in-process code since internal
interfaces have been slightly revised. This means that the shell is no
longer using any native code for drawing the calendar dropdown.
https://bugzilla.gnome.org/show_bug.cgi?id=641396
Signed-off-by: David Zeuthen <davidz@redhat.com>
See commit f2158218bef0c51 in mutter. Basically, we need
to grab org.freedesktop.Notifications before anything else
in the session gets started.
Note: I intentionally removed the Util.killall bits. I believe that
for notification-daemon at least, if we specify
DBUS_NAME_FLAG_REPLACE_EXISTING, we'll take over the name. Not sure
about notify-osd; if that's still a problem, then what we need to do
is add killing (and possibly respawning) of notify-osd to
"gnome-shell --replace", and not have it embedded randomly in a JS file.
https://bugzilla.gnome.org/show_bug.cgi?id=642666
Commit 259c84ed9a refactored out HotCorner into its own class
and added this line and a variable, but it was left behind
when the variable disappeared in commit 7cf311dac0.
Currently the panel is positioned from main.js, move that code into
a method in panel.js instead and call it from main.js, which is
consistent with what we do for the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=643064
A PolicyKit Authentication Agent is a construct used to authenticate
one or more identities. See the PolicyKit documentation for more
details on authentication agents and how PolicyKit works:
http://hal.freedesktop.org/docs/polkit/
Since gjs does not support subclassing a GObject class from Javascript
code, we bring in a native class to bridge the VFuncs to GObject
signals. Additionally, this native class also queues up authentication
requests so the user of the native class only has to deal with a
single outstanding request at any one time.
The file js/ui/polkitAuthenticationAgent.js introduces a singleton
that listens for authentication requests via the native class. This
singleton uses the PolkitAgent machinery to do the actual heavy-weight
lifting required for authentication (essentially a PAM conversation).
We currently don't allow the user to pick the identity to be
authenticated.
https://bugzilla.gnome.org/show_bug.cgi?id=642886
Signed-off-by: David Zeuthen <davidz@redhat.com>
The Overview does not only hold the different elements visible in
the overview, but is also a central point to manage drag signals.
As objects which are constructed in the overview constructor cannot
access Main.overview (as its constructor has not finished yet), we
use misnamed show/hide methods to work around this limitation, which
are called when entering/leaving the overview.
A better way to handle this problem is to remove the limitation
altogether by splitting the overview constructor between internals,
which remain in the constructor, and more complex objects which
need to access Main.overview, and whose initialization is moved
to a public init() function which is called by main.js after the
overview has been constructed.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
The new plans for a row of workspace thumbnails on the right side of the
overview means that the mental model we present to the user will be
vertical, so switch the Metacity workspace layout to be vertical and
adjust the keybinding handling, animations, and workspace layout in
the overview to match.
(This commit does not change the workspace switching indicator pending
finalization of what we want to do with that - it still shows workspaces
arranged vertically.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Right now popModal() passes global.get_current_time() for
its begin_modal() call. global.get_current_time() is the
timestamp of the last gdk or clutter event processed by the
shell's mutter process. These values could potentially be
be too stale to use if pushModal() were to get called in
response to an event by another process.
This commit changes pushModal() to have an optional timestamp
argument, which can be used to associate the call with the
event that initiated it.
https://bugzilla.gnome.org/show_bug.cgi?id=637187
Add Util.spawn, Util.spawnCommandLine, and Util.spawnDesktop for
spawning a command/argv/.desktop file in the background, automatically
handling errors via MessageTray.SystemNotificationSource(), and
Util.trySpawn, Util.trySpawnCommandLine, and Utils.trySpawnDesktop
that don't do automatic error handling (but do at least clean up the
error message in the exception a bit).
Update various other bits of code around the shell to use the new
methods.
https://bugzilla.gnome.org/show_bug.cgi?id=635089
Although certain keys (like Ctrl-Alt-Tab and Alt-F2) should work in
the overview, we generally don't want them to work from inside each
others grabs. In particular, typing Left or Right from inside
Ctrl-Alt-Tab should navigate among focus groups, not switch
workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=636971
Also, change _globalKeyPressHandler to handle KEY_PRESS, not
KEY_RELEASE, for consistency with other code (and so that the
combination of an Alt-F1 press and release doesn't first enter the
overview and then immediately exit it).
https://bugzilla.gnome.org/show_bug.cgi?id=636371
The gnome-panel allows the user to hover over a tasklist entry
while draging to activate a minimized or obscured window and drop onto it.
Implement a similar behaviour by allowing draging to the activities button or
the hotcorner (and thus opening the overview), which allows the user to
activate any window (even on different workspaces) as a drop target.
https://bugzilla.gnome.org/show_bug.cgi?id=601731
Until recently, the clutter keyboard focus was almost always kept on
the stage, and bits of code that wanted to do stuff with the keyboard
would just watch for key-press-events on the stage. In several places,
the code wasn't even bothering to ensure that the focus was on the
stage, which caused problems with other actors that explicitly grabbed
focus.
A previous fix for this (f21403fd) was to always reset the focus to
the stage after calling pushModal(), but a better fix is to just
actually make use of the keyboard focus everywhere rather than having
everyone try to read events off the stage.
Now pushModal(actor) also does actor.grab_key_focus(), and various
bits of code have been changed to read key events off their own
toplevels rather than off the stage, meaning there's no chance of them
accidentally getting someone else's events.
https://bugzilla.gnome.org/show_bug.cgi?id=618885
The code to draw the root background has now been moved into Mutter,
with added smarts to not draw obscured portions. Remove the old
version of the code and clone the Mutter background actor to draw
the background in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=634836
This way the new modal level is independent of whatever may have been
happening before. Fixes a problem with status menus becoming active
again from inside the app switcher, etc.
