Some of the conditions for showing the user list were not
properly inverted, causing the session list to be hidden
when it shouldn't be and shown when it shouldn't be.
https://bugzilla.gnome.org/show_bug.cgi?id=694784
As a special-case to the "cap event" rules, this allows a heavy swipe
from top to bottom to allow triggering the tray without having to push
into it.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
When pressing against the bottom of the screen, we shouldn't
really take more than 15px from each event, to prevent spruious
mouse movements from opening the barrier.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
gnome-settings-daemon will be changed to override the XSetting in
the case where we're on a remote display rather than overwriting a
user setting, so we need to look at the XSetting here.
https://bugzilla.gnome.org/show_bug.cgi?id=694320
Previously, we would create one StBin per monitor, but each was positioned
at 0,0 and sized as the screen, so they would overlap and draw the box shadows
on top of the other backgrounds.
Instead, we need to size appropriately the bin, and then we need to position
the actual MetaBacgroundActor at 0,0, so add a flag to BackgroundManager
for this.
Also, get rid of MetaBackgroundGroup, they do nothing because the screenshield
is not a descendant of the MetaWindowGroup and because the widget in between
blocks the propagation of the visible region. At the same time, use a
widget, not a bin, because StBin requires you to set .child, not call add_child().
https://bugzilla.gnome.org/show_bug.cgi?id=694394
We recently started to trim leading and trailing whitespace from
the search string, and not to trigger a search when the resulting
string was empty. However we still allow whitespace to trigger
type-ahead-find, so that the key focus is moved briefly to the
search entry and back to the stage, resulting in a disruptive
flickering of the entry.
Fix this by excluding whitespace from triggering type-ahead-find.
https://bugzilla.gnome.org/show_bug.cgi?id=694475
xdndHandler used to wait for the stage to show up before calling
global.init_xdnd() . Since commit 65303d027a xdndHandler is initalized
later so the stage might be already visible at this point causing the
show signal never to be emitted and thus global.init_xdnd will never
be called.
Fix that by checking by calling global.init_xdnd without waiting for
the stage's show signal to be emitted, as the stage is guaranted to be
visible at this point.
The key was removed from gsettings-desktop-schemas, GNOME should
always draw a background: the key existed to support xsetroot, but
we no longer read the _XROOTPMAP_ID.
https://bugzilla.gnome.org/show_bug.cgi?id=694463
If the AllView is scrolled, the vertical scrollbar will take away
some horizontal space on one side, resulting in the content ending
up slightly off-center.
Account for this by using overlay-scrollbars instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
The frequent view should not be scrolled, but to work around the
icon grid overflowing, we used a (non-scrolling) scroll view anyway.
Now that IconGrid:fillParent allows us to avoid overflow, we can
remove this hack.
https://bugzilla.gnome.org/show_bug.cgi?id=694256
We sometimes map the stage before we've loaded a background on it
because of a race asynchronously loading the session mode.
This manifests as the startup animating starting over a white
background.
This commit defers showing the stage until after the still frames
are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
It is useful at times to perform several actions that would usually
close the overview (for instance launching an application) at once.
Currently we allow this by dragging items to a workspace rather than
just clicking it, but it's an odd metaphor with its own set of
problems.
Introduce an alternative approach (inspired by file selection in
file managers) by keeping the overview open if a Control key is
held down.
https://bugzilla.gnome.org/show_bug.cgi?id=686984
When the user clicks on "View Source" or "Web Page" in the "Extensions" tab of
looking glass, the callback _onViewSource() or _onWebPage() is called and they
try to close looking glass: this._lookingGlass.close();
But it does not work and generate the exception "this._lookingGlass is
undefined". This patch fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=693814
animateIn and animateOut should not reset the scale, otherwise
extra animate calls (which are possible because the diff algorithm
in _redisplay is not optimal) cause unneeded movement.
Therefore, create new items hidden, and have the creator call
animateIn or set the scale/opacity properties manually.
adjustIconSize must be changed to always set the icon size temporarily,
otherwise the first time it computes the icon size with 0 scale.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
The DashActor will known to allocate the show apps button only if the
icon size is (temporarily) too big for the containing box, therefore
it should request just that as the minimum size.
This solves a glitch that happened when removing a favorite and at the
same time causing the dash to expand.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
Using the scroll wheel in the window picker should switch workspaces.
As the picker doesn't have a visible boundary though, it makes sense
to accept scroll-event for the entire overview area. Rather than
making the overview's main actor public, expose scroll-events via
a signal.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
Using the scroll wheel to switch workspaces makes sense, but it is
currently only supported on the workspace switcher, as it conflicts
with window zooming in the picker.
As changing workspaces is far more useful than the zoom feature,
remove the latter in order to "free" the scroll wheel for workspace
switching.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
Right now if a user logs out, they are thrown to the login screen
imediately, without even seeing the dialog close.
This commit fades the dialog out before processing the logout.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Opening and closing a modal dialog is not instant. There
is a transition animation involved. When the dialog is
finished opening, it currently emits the "opened" signal.
When it's finished closing, however, it doesn't emit a
"closed" signal. This means, there's not a good way to
know when the dialog finishes closing.
This commit adds the "closed" signal.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Modal dialogs take an optional timestamp in their close method.
If the timestamp is not passed in, then global.get_current_time()
is used.
Some callers of the close method pass in global.get_current_time()
unnecessarly (since it's the default).
This commit drops the argument for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
And reverse menu order in order to avoid it reading "Change Background… Settings"
"System Settings" shouldn't be used because it's not used to mean the control-center in any other place.
https://bugzilla.gnome.org/show_bug.cgi?id=694290
We disable the entry after a user answers a question while we
process it, but we don't reactivate it later if asked another
one.
This commit makes sure the entry is always reactive when we
are waiting for an answer from the user.
https://bugzilla.gnome.org/show_bug.cgi?id=691806
When a swipe scroll completes, we scroll the active workspace into
view. This works fine if the gesture is completed properly by
emitting 'gesture-end', but not when Clutter considers the gesture
cancelled - in that case, the view remains stuck in an intermediate
position. To fix, treat 'gesture-cancel' the same as 'gesture-end'.
https://bugzilla.gnome.org/show_bug.cgi?id=689394
This means that windows will be positioned correctly with respect
to the panel when the shell starts up, and there won't be adjusting
after the session animation zooms in entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Due to a bad rebase causing freezeUpdateCount to never get initialized,
these functions effectively did nothing. Since we're going to go to a
different mechanism for freezing region updates, let's just tear these
out now instead of fixing them before tearing them out.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
PopupMenuManager eats the next release event, which would otherwise close
the menu, so we need to tell dnd that we're handling it, and no drag should
be started, so it can ungrab the pointer and restore state.
https://bugzilla.gnome.org/show_bug.cgi?id=694276
The arrow origin must be in the coordinate space of the box pointer,
but it cannot be calculated when the box pointer is shown, because it's
not allocated yet, so pass the source to the boxpointer and adjust
the arrow at the next paint.
https://bugzilla.gnome.org/show_bug.cgi?id=694264
St.Bin() really only expects one child at a time, and the
BackgroundManager will add two. This can cause assertion
failures when destroying one of the background actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
BackgroundMenu must ensure the actor it attaches to is reactive, and
the layout manager must create a background menu for the first background
too.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Right now we arrange the window thumbnails in a grid if there are more than two
rows of them. This was originally intended to reduce the amount of noise in the
thumbnail arrangement. It also made sense when the thumbnails were of a similar
size.
Nowadays we reflect the size of windows in the size of the thumbnail. This
leads to huge amounts of space between some windows when they are grid aligned.
Removing the grid alignment would also lead to larger thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=694210
Right now we hide the window group if we're a greeter.
We did this to avoid showing the background. These days
we don't add the background in the first place, so we
can drop this code.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
gnome-desktop's background drawing code supports an
XML format for presenting backgrounds based on time of day,
monitor geometry, etc. Now that we don't use gnome-desktop for drawing the
background, we need to implement that support ourselves to maintain
feature parity.
This commit implements that.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
This commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.
Based on initial work by Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The user list and the "Not Listed?" button get shown and hidden at the
same time, so we can simplify the code by putting them in a new
subcontainer.
This commit creates a userSelectionBox container that both actors get
put in, and changes all the code that shows and hides these actors to
show and hide userSelectionBox instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
The sessionList and the prompt hint are all really
part of the prompt, so we should have the code that
hides those things in hidePrompt instead of in
showUserList.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now, when a user item is clicked we remove all other users from
the list and position the item in the appropriate place on screen.
Ultimately, we're going to want to crossfade from the fully populated
list to the user prompt. Since we're going to need to show the user
avatar in two different positions we can't simply move it.
This commit leaves the user item for the user list, and instead shows
a UserWidget actor during user verification, in the same way the
unlock dialog shows a UserWidget actor during reauthentication.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
The user widget is the username and avatar shown on
the unlock dialog.
The login dialog has something very similar.
This commit separates the user widget out to its own
file, so we can use it from the login dialog in a
later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
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
The latest mockups don't animate between states by
resizing actors. Instead, crossfades are employed.
This commit strips out many of the existing animations
as a first step toward implementing the new ones.
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
