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
Since commit 1ae0fadbf4 we
no longer start a PAM conversation as soon as the user clicks
the "Not Listed?" button. Instead we defer starting the PAM
conversation until the user types their username.
Unfortunately, the cancel button resets the dialog back to the
user list indrectly by cancelling the current PAM conversation.
This means if the user hasn't yet entered thier username then
the cancel button doesn't work.
This commit performs a direct dialog reset in the case the
PAM conversation hasn't been started yet.
https://bugzilla.gnome.org/show_bug.cgi?id=693756
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
