Right now we very abruptly kill the login screen
and start the users session without any transition
out.
This commit introduces a fade out of the dialog and
panels.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
According to the design mockups, the app picker should follow the
recent view pattern as used by applications, where the user is first
offered a subset of applications he/she is likely to start, and only
then allow switching to the full set of installed applications.
So implement the ability to manage several views in AppDisplay and add
FrequentView as additional view, which uses the existing ShellAppUsage
to display a list of frequently used applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
While a group is open, we want to block events on items underneath,
but still allow interaction with components outside the app display
as well as scrolling of the view as a whole.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
App folders are intended for grouping some applications, not to
assign a category to every single application, so we will only
create folders for a selected subset of the existing categories.
Software/Alacarte will eventually allow to create/modify those
folders, so store the setting in GSettings so that it can be
shared with those applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
At the moment when loading the applications, each app is inserted
at its correct (alphabetical) position. Avoid this overhead by
loading all apps first, then sort them once and fill the grid with
the sorted actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AllView will be updated to allow app folders in addition to app
launchers. Folders will pop up in the existing view, so add an
additional stack widget into the hierarchy which popups will use
as parent.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
We are going to introduce app folders, which will also present an
alphabetical list of applications, but use a different UI. In
preparation for that, split out the item logic into an abstract
base class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
With categories removed, the separation between AllAppDisplay and
ViewByCategories no longer makes sense. Also use this opportunity
to rename the outdated AllAppDisplay to AppDisplay; it will
eventually be used to manage different views.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AppIcon is just a tiny wrapper around BaseIcon, which does not add
anything over using BaseIcon directly, so merge its code with
AppWellIcon. As the concept of the "app well" has not been used
since well before 3.0, use AppIcon as name for the merged class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
Doing it before the grab messes up the grab helper's tracking
of where the focus was before, leading to it not tracking the
saved focus correctly, meaning that when we pop the menu back
down with escape, it doesn't restore focus correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=694123
Starting the startup animation when we don't have that much IO
makes it a lot more visible.
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=682429
commit 92083eaf76 made
session mode loading an asynchronous operation.
Aspects of the session mode aren't known immediately at
start up. For instance, sessionMode.isGreeter returns
false for greeter sessions until the asynchronous
operation completes.
This commit defers start up processing until the session
mode is fully known.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The complex overview transition code means that there's no easy
way to handle with this right now. Blocking the message tray
while the overview is animating seems like the correct thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
The activities button may come and go at any moment now that we
have a dynamic panel. We need to re-check the activities button
whenever the panel is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
Making them not fully opaque just makes them harder to see and there is no reason why the user should care whether the window is minimized or not when
switching to a window display them like any other windows.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
Alt-Tab away from a monitor sized on the primary monitor results into the top
panel being displayed on top of the window which looks very bad.
So just hide those windows by minimizing them.
The icon geometry animation does not really make sense for fullscreen windows
so just fade them out.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
All the complexity with a custom actor and a generic container was
just to add some padding below the overview controls. Remove that,
and use CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694100
Since GNOME 3.6, switching XKB layouts changes the group
configuration. This patch tries to track group configuration changes
and reconstruct UI as needed. See also caribou bug#694011.
https://bugzilla.gnome.org/show_bug.cgi?id=681735
Commit 6b4f524620 removed the layer checks
_updateFullscreen ... this causes corruption when alt-tabbing out
of a fullscreen window so restore the check.
The commit also removed the screen sized check so we are no longer
setting all monitors to fullscreen. Fix that as well by using
window.is_screen_sized() to perform the check.
https://bugzilla.gnome.org/show_bug.cgi?id=694079
If the animation time is not the same for these two, the translation
will be adjusted to the allocation during the tween, resulting in a jump
in the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=694035
The top_window_group blocks the panel elements from being found by the XDND
pick so hide the whole group from picks as we never attempt to pick its contents
anyway.
Account for the search entry space at the bottom (the former message
tray clone) individually in each side control, instead of packing
another actor in the overview.
This allows us to extend the central view all the way to the bottom,
while still keeping controls centered vertically.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
Don't show the message tray in the overview by default. From now on the
message tray in overview behaves as regularly, i.e. it will slide up the
overview on Super+M keypress.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
StBoxLayout always fills on the orthogonal direction, so the icon
becomes distorted as the layout grows to accomodate more details.
Instead, use a bin that aligns at the start.
https://bugzilla.gnome.org/show_bug.cgi?id=693822
ScreenShield uses Notification.bannerBodyText to fill the body of detailed
notifications, so use a separate boolean property to indicate it was already
added to the body.
https://bugzilla.gnome.org/show_bug.cgi?id=693822
Calling onUngrab() may change key focus, either directly or
indirectly (e.g. hiding the actor). Such key focus changes
would cause an extra actor to be ungrabbed, so make sure to
ignore such focus changes while we're ungrabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
If we don't this for a nested grabFocus grab, the notify::key-focus
will be called, not think that the new key focus is part of the
grab, and cancel the full grab. This leaves the grab helper in an
inconsistent and confused state, as the grab is pushed onto the
grab stack after.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
While debugging, I found that the signal to focus-window-changed
was never getting disconnected, making a call to ungrab every time
the focus window changed, even if there were no focus grabs anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
When we reset the state of the checked button due to the overview
showing and hiding, block the normal checked callback and immediately
switch to the workspaces page, so that windows seamlessly fade in.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Set the checked property explicitly. This is because
resetShowAppsButton() will only be used to flip the button state
blocking the page change in a future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
And use it in overviewControls. When we moved this code from overview.js
to overviewControls.js we lost a condition so we now slide in controls
even when going back from the overview, which looks bad.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Early on, search was based on a list of terms, which was like a set
of tags, in that terms were OR'd, and that order didn't matter. As
such, modifying any one of the terms wouldn't produce new results.
Nowadays, providers take the order into account, so a substring
should only be the case if new terms are added to the end.
https://bugzilla.gnome.org/show_bug.cgi?id=693935
If WindowOverlay.relayout() is called without animation, we must stop
any preexisting animation, otherwise it will continue to run with the
previous parameters and cause the overlay to end up in the wrong position.
https://bugzilla.gnome.org/show_bug.cgi?id=693970
The slideX property controls the allocation of the view selector; since
we now know when there are no visible views from the page-empty signal,
we can use it to set the full slideX for the next page at that time,
allowing the new view to fade in with the right width.
This allows us to use simple x translations for the side components when
switching pages, keeping the noise due to resizes at the minimum.
The slideX resize for now is kept for DnD, and will always be needed for
the thumbnails box when showing the windows page.
https://bugzilla.gnome.org/show_bug.cgi?id=693924
If we increment our index variable while looping, this means that
firstNewEvent will be one higher than it should. With a length 1
array, all events will be removed, so this has a cascading effect
that events will not be stored at all.
https://bugzilla.gnome.org/show_bug.cgi?id=693854
