Right now we have two booleans that specify when user verification
is happening and when it succeeded, respectively.
This commit consolidates them into one AuthPromptStatus enumeration.
This clean up will allow us to check for verification failure more
easily.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
The only time we ever call _reset directly is when
detecting changes to disable-user-list. We can implicitly
trigger a reset for this case, just as easily by calling
this._authPrompt.reset()
This commit makes that change for consistency and to make
it easier to adjust the authprompt workflow later.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
When we shift workspaces to create a blank one for a window or
application, all of the window actors are shifted down. However, some
of these window actors are transient windows attached to a main window.
When these windows are moved to a different workspace, the main window
is moved along with it. When the main window is moved, these windows
are also moved. This creates a double move of the windows.
This double movement leads to unexpected results where workspaces are
collapsed and windows are in incorrect positions.
This patch prevents movement of these transient windows, only grabbing
the main (ancestor) windows to move to a different workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=705174
Right now the whole authPrompt spreads out if a PAM message
comes in that longer than the entry.
This commit changes it to wrap instead, by forcing the
auth prompt to be a fixed width (slightly bigger than
the entry width was sized to previously).
https://bugzilla.gnome.org/show_bug.cgi?id=705037
Remove the Wi-Fi chooser from the menu and put it in a dialog instead.
This frees up the submenu to simply have three items: an rfkill toggle,
a button to show the dialog, and a button to show network settings.
Ideally, we'd autodetect the "needs network" case by user initiation
and automatically show the dialog if needed, but lower-level plumbing
is neccessary, so the menu item to show the dialog is an acceptable
compromise instead.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Since the network section of the aggregate menu will be shown in the lock
screen, we need to ensure that users can't tweak with network settings or
anything like that.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Replace NMNetworkMenuItem with NMConnectionItem, based on
NMVPNConnectionItem, and replace NMDevice with NMConnectionSection
and NMConnectionDevice.
Since this rips apart NMDevice, and since wi-fi should not be
connection-based, we'll temporarily remove NMDeviceWireless. We'll
add it back in a later commit, along with the new Wi-Fi dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
Instead, just add them after they're constructed. This allows us to
not have to pass the connections to each device, and prevents issues
with having to enumerate the connections in the middle of construction.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
Note that this does have an interesting side effect of not showing
network connectivity status on wired. This is intentional, and error
states will still be shown in the top bar when they happen.
This also means that if you're connected to both wired and wireless,
even though wired is the default route, we'll first notice the wireless
active connection, and we'll show that in the top bar. New NM API that
will help figuring out the active connection of the default device is
being implemented to stop this from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
The code is complicated by requiring overflow, and in order to incrementally
improve the code to match the designs, remove overflow.
In the new design, we'll have a fixed number of menu items, and Wi-Fi
will be done by a separate design, so we can't be too concerned with
the menu not fitting on the screen.
This is a part of the new system status design, see
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/
for design details.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
According to Dan Williams, if firmware is installed the device
will disappear and reappear, and this is unlikely to change any
time soon. Just make our lives easier by removing the tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
I intended to make a few code cleanups, but I apparently forgot
to hook up _updateAccessPoint. Merge it with _activeApChanged,
which is where the notify::active-access-point signal is actually
hooked up to.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
As we only reload search providers on startup or when the sort order changes,
and given the small number of search providers we'll actually load, I doubt
we'll see any speed decrease.
The simplicity of synchronous code is also much clearer, and fully avoids
all the possible bugs about in-flight requests or similar.
This also prevents issues with multiple search providers showing up at once,
which happen when multiple requests to reload search providers get called
immediately, with the existing in-flight async requests never cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
When we reload the remote search providers, we currently try to remove
all remote providers, and then re-scan. It turns out that we sometimes
remove the wrong providers from the remote provider list, causing us to
have some providers not correctly unloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
When a ShellUserVerifier is asked to verify a user at the login
screen it will transparently first try to reauthenticate the user
against an existing session and then fall back to logging a user
into a new session. The former is used for user switching.
It's useful to know which type of verification is happening, so
the next button can be made to say "Unlock" instead of "Sign In" when
a user is already signed in.
This commit exports a new "reauthenticating" property on the
ShellUserVerifier that the auth prompt checks when deciding which
label to use for its next button.
https://bugzilla.gnome.org/show_bug.cgi?id=704795
If there are no messages in the queue and a user starts to
type then we can safely hide the message label since the
user has probably already read it.
This fixes a weirdness where "Incorrect Password" messages stay
around, even as the user types in the new correct password.
https://bugzilla.gnome.org/show_bug.cgi?id=704817
Similar to our ClutterContainer monkey-patching, we can add some
convenience to existing ClutterLayoutManagers:
- hookup_style() to bind layoutManager properties to CSS properties
- child_set() to set child properties
https://bugzilla.gnome.org/show_bug.cgi?id=703905
Jasper removed the ShellGlobal:stage-input-mode property after its
"last" use was removed. Adapt the (hopefully) really last use of the
property to the recent input changes.
https://bugzilla.gnome.org/show_bug.cgi?id=704095
There's quite a bit of duplicated code between the login dialog
and the unlock dialog dealing with the various signals from the
ShellUserVerifier.
This commit moves that duplicated code into the AuthPrompt.
https://bugzilla.gnome.org/show_bug.cgi?id=704707
The point of fading the icon is to make the text displayed over the
icon more legible. In RTL layouts, the text is displayed on the left
of the icon, so fading the right-hand-side of the icon doesn't work
well.
https://bugzilla.gnome.org/show_bug.cgi?id=704583
This is a regression from splitting the slider out that never got fixed.
Restore the previous (useful) behavior by adding a public API to the
slider that lets us pass an event through.
https://bugzilla.gnome.org/show_bug.cgi?id=704368
We've long had the hasWorkspaces property, but it doesn't seem like
it was ever used. Implement it so that we don't have workspaces in
initial-setup mode.
Since it's difficult to make it change at runtime with a decent set
of semantics, and we never expect that to happen, don't bother
implementing it dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=698593
commit ea02380c15 made the login
screen stop using ModalDialog. It makes sense for the unlock
code to also stop using ModalDialog, too (for similar reasons).
Now that the login screen's auth prompt code has been separated
out, the unlock dialog can use it to get the buttons and spinners
etc, that it was previously getting from ModalDialog.
This commit drops the ModalDialog usage in the unlock dialog, and
makes the unlock dialog use GdmUtil.AuthPrompt instead.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now there is a lot of duplicated code between the unlock
dialog and the login dialog.
This commit moves the login dialog's auth prompt to a separate
class, so that it can (in a subsequent commit) be used by the
unlock dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
A bug got introduced when moving the login dialog away from modal
dialog, such that it listens for escape key presses in a mouse
event handler instead of a keyboard event handler.
This commit fixes that code to correctly listen for key-press-event
instead of button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now if disable-user-list is true we show it briefly, just so
that we can fade it out to the user entry.
This commit avoids the fade in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=704471
Right now when a user types their password to unlock their session
we end up getting an unlock signal from GDM right away. We then
proceed to deactivate the screensaver before the user has a chance
to read his messages.
This commit makes sure we clear out the message queue before processing
the deactivation request.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
logind sends out an "unlock" signal separately when
verification completes and we already listen for that,
so we don't need to unlock on verification-complete, too.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
this._clearMessageQueue() is a noop when this.hasPendingMessages is
false so calling it in that case doesn't make sense.
This commit drops that call.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
Add an option to limit the appSwitcher to the current workspace. For users
that use workspaces for task separation this more convient then current
behviour. While having to add an option is unfortunate there is no way to make
both groups happy as workspaces usage differes between different users / types
of users.
https://bugzilla.gnome.org/show_bug.cgi?id=703538
We need to make sure that we reset the opened submenu when we close the
submenu, not trick the toplevel into thinking a closed submenu is the
currently opened menu.
https://bugzilla.gnome.org/show_bug.cgi?id=704336
This way, if a parent is insensitive, all children will be, too.
Though PopupSubMenus will be forced closed, PopupMenuSection needs
the propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Doing it at the end has confusing semantics, especially as there is
this point where isOpen is true, but the corresponding open-state-changed
has not been emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
It seems this behavior at one time was intentional, but I (along with
the designers) think it looks ugly having the menu having its insides
shrinking and shifting around while fading out of existence.
There's two cases where we currently explicitly try to animate the
submenu closed -- when an item is clicked inside the submenu, and
when the toplevel closes. This removes both of those.
The user expectation is that submenus will be closed the next time the
toplevel is open even if they were open before, so force submenus closed
when the toplevel finishes fading out, without any animation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
As the aggregate menu will be built out of sections from each
of the menus, we need to ensure that activating an item in one
of these sections can close the main menu, even when it is not
a menu item. The new API also needs to be flexible enough to
ensure that animations can be controlled, like the buttons that
lock the screen or launch a new session.
Port the user menu to use this new API as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Now that we preallocate space for the prompt message there is
a lot of loose space between the entry and the buttons.
This commit helps tighten things up by getting rid
of the large top padding set above the login buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
A PanelMenuButton added to the top bar might not be visible at all
times. If it is hidden while the corresponding menu is open, we
currently don't do anything at all, e.g. the menu remains open
pointing to an arbitrary location in the top bar.
Instead, close the menu automatically in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=703540
The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
commit ea02380c15 changed the login
dialog to not use ModalDialog anymore. There's still one lingering
setInitialKeyFocus method call in the source, which will cause an
exception to be thrown when users have their user list disabled.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=703874
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.
Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.
Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.
Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.
At the same time, remove the FOCUSED input mode, as it's no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.
This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.
This also removes our only use of focus grabs, so remove those
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
We can't assume "isActive implies isModal", so there is a risk
of pushing a modal that nothing else will ever pop, because we
take the early return and don't activate the user active watch.
https://bugzilla.gnome.org/show_bug.cgi?id=700901
_updateIcon should not attempt to sync any active connections, as the
icon-changed signal can be emitted in response to something done during
_syncActiveConnection. In the case of VPN, removeActiveConnection would
cause an icon-changed signal to be emitted immediately, but the state
would not be updated, causing us to call removeActiveConnection over and
over.
Explicitly sync all active connections when we know it needs to be done,
and simply make _updateIcon synchronize with the current device's icon.
https://bugzilla.gnome.org/show_bug.cgi?id=703565
This fixes a blue background being drawn when switching the monitors
configuration using hardware keys
(clone/multimonitor/external/internal).
The problem is that the shell gather all background loading requests
under the same meta_background_load_file_async call using one
GCancellable (the first one to come). So when the shell receives a
batch of 12 or so XRandr events, it creates 12 new background managers
which end up trying to load 12 times the same background picture. All
of these requests are batched into the same
meta_background_load_file_async using the first GCancellable received
on the first request. Unfortunately, when the first request is
cancelled by the following event indicating a new monitor setup, all
of the background picture requests are dropped on the floor, and
nothing gets loaded (hence the blue screen background).
https://bugzilla.gnome.org/show_bug.cgi?id=703001
It turns out that picking a 3200x1200 scene on notebook chipsets
every time the mouse is moved isn't exactly the fastest thing. Defer
picking to an idle to ensure that it won't get in the way of keeping
up with mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=703443
The code that checks for various conditions is confusing and
undercommented. It appears one of the recent refactorings
inadvertedly inverted the sense of the 'hidden mountpoint'
check, and caused autorun to not work for anything that does
not have a 'native root' - which is pretty much all volumes
implemented by gvfs.
https://bugzilla.gnome.org/show_bug.cgi?id=703418
Commit d6cace32 introduced a typo in the left/right arrow side
calculation code that causes in most scenarios (where the monitor
width is greater then the height) to not flip the box when it doesn't
fit inside the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=703403
If the drag action ends after something else has put the screen shield
into a different state we can end up in an inconsistent screen shield
state where the whole thing is empty.
https://bugzilla.gnome.org/show_bug.cgi?id=703126
There are some issues with the existing session menu. First, it looks
kinda bad. It seems like it's hanging around there, but it doesn't really know
what to do with itself.
Second, when it expands down it requires that the buttons below move
down with it. This kind of movement is awkward and looks a bit weird.
Third, its current position makes the "dialog" tall and unwieldy when
you add things like messages for fingerprint readers or authentication errors.
This commit moves the session list to a menu behind a button to address
the above problems.
Based on a patch by Jasper St. Pierre.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
Commit 16fa186b63 attempted to fix the zoom animation problem
by throwing changes on the floor while the overview is animating. This has
the side effect that we might end up missing some positioning changes causes
windows to overlap the workspace thumbnails.
So revert those changes and fix it by simply by passing
WindowPositionFlags.ANIMATE during the overview animation.
This way the animation works as expected and we don't miss any position changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703105
Right now, there's a weird flicker at start up where the
Not Listed? button shows up before the user list, which looks
pretty bad if you're watching for it.
This commit fixes that problem by hiding the Not Listed button
initially and showing it at the appropriate time.
https://bugzilla.gnome.org/show_bug.cgi?id=703132
The top_window_group was introduced for popup windows that should
appear above system chrome, but as the group itself is just a child
of Main.uiGroup, chrome that is added after top_window_group will
still be stacked on top.
At least correct the stacking for actors added via addChrome().
https://bugzilla.gnome.org/show_bug.cgi?id=702338
The login screen is no longer even remotely dialog-like, so
using ModalDialog is pretty weird. It also makes it difficult
to put the session list in the same place as the spinner.
This commit moves loginDialog away from using modal dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
The class is generally useful, so it only makes sense in panel.js
for historical reasons. Because other parts of the code are
using it, though, problems are cropping up that require a
workaround like:
placeSpinner: function(...) {
/* This is here because of recursive imports */
const Panel = imports.ui.panel;
Panel.AnimatedIcon(spinnerIcon, WORK_SPINNER_ICON_SIZE);
...
}
This commit moves AnimatedIcon to its own file so we can drop that
workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=702818
When the osd window is hidden based on the timeout, it accidentally
left the timeout ID in place. When a subsequent switcher popup came
up, it thought the OSD window was scheduled to be hidden and tried
to re-hide the actor. This caused the tween to be run along with
an extra call to enable_unredirect_for_screen.
When the allocation of the workspacesView changes during the animation we override
the tween with one that does not animate causing the overview zoom animation
not to happen.
Fix that by ignoring the alloactionChanged notification during the overview
animation.
The code here before was trying to play hierarchy tricks to
figure out how to show / hide the events list, which broke
when we rearranged how the date menu was laid out. Simplify
the code here to not be so tricky, and update the CSS to
match the new designs.
https://bugzilla.gnome.org/show_bug.cgi?id=702849
The timestamp timeout specifies how long we should wait before
adding a timestamp to the notification. A timeout of one minute
ended up showing a lot of timestamps, so increase it to 3 minutes.
https://bugzilla.gnome.org/show_bug.cgi?id=687809
If we focus notifications before they're expanded, the body and action
area won't be visible, and the can_focus members like the text entry
will not be able to be focused.
Ensure that all of the all actors that would be in an expanded notification
are visible before we attempt to focus them.
https://bugzilla.gnome.org/show_bug.cgi?id=698778
Migration from old settings can result in a path instead of URI
there. This is technically invalid, but can easily recognize it
and avoid the crash.
Minor changes by Ray Strode
https://bugzilla.gnome.org/show_bug.cgi?id=702121
The status item will go away soon, so make sure the one-time
fire is given its own function. At the same time, only connect
to the signal when the situation actually matters.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
No class in here has this.carrier as a property. Presumably, this was
meant to be this.device.carrier, but since this code is going to be
rewritten soon anyway, might as well just junk the never-working
code for now.
https://bugzilla.gnome.org/show_bug.cgi?id=701954
In order to have event descriptions on multiple lines, but still
maintain proper alignment with the day and time strings, refactor
the whole event list to be one big table. Headers are implemented
as spanning cells, and uneven spacing is a mix of row/column spacing
and cell padding.
https://bugzilla.gnome.org/show_bug.cgi?id=701231
In BlueZ 4, Authorize() was used to authorize both service
and JustWorks authorization requests. In BlueZ 5 these two
have been split into AuthorizeService() for services and
RequestAuthorization for JustWorks devices. Adapt the
Bluetooth code accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=700891
This can be more easily achieved by listening for changes to the
device's active-connection property. VPN will still need support to
track active connections, as it does not have an associated
device. But as VPN can track multiple active connections, the names
"set" and "clear" don't quite fit. Rename them to the more-standard
"add" and "remove".
https://bugzilla.gnome.org/show_bug.cgi?id=701954
The end session dialog was waiting a second before updating
its text to display the timer. It is nicer to show the correct
message from the start.
https://bugzilla.gnome.org/show_bug.cgi?id=702056
We currently monitor the shell's override schema for changes to
the 'dynamic-workspaces' key, which ends up being the wrong
schema in classic mode. With the new ability to use mode-specific
overides, we can finally fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
This will allow the use of mode-specific defaults. For classic mode
we currently implement this with mini-extensions, but this may result
in confusing behavior when settings change due to extensions being
disabled during screen locks (not to mention that those mini-extensions
are hardly an elegant approach).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
As multiple-connections for a Wi-Fi AP won't fit in the new design,
remove submenus right now. Simply make a simple item that connects
to the first known connection for the AP, which should be the common
case.
https://bugzilla.gnome.org/show_bug.cgi?id=698918
Currently we "only" grab the keyboard when starting a drag operation,
which does not impede keybindings to be processed. This is at best
not harmful (like workspace switching), but may have unintended effects
otherwise - for instance, the hot corner is disabled, so having the
corresponding keyboard shortcut still active is fairly odd (not to
mention that it leaves the system in a confused state).
Fix this by switching to pushModal()/popModal(), which will push a
dedicated keybinding mode for us.
https://bugzilla.gnome.org/show_bug.cgi?id=700877
Currently the clipboard's contents may leak to unauthorized parties by
pasting into the unlock dialog's password entry and unmasking the entry.
Prevent this from happening by clearing the clipboard on lock.
https://bugzilla.gnome.org/show_bug.cgi?id=698922
When the dash does not contain any applications (either favorites
or running), it is currently impossable to add a favorite via DND.
Grow the dash slightly in that case to provide a drop target.
https://bugzilla.gnome.org/show_bug.cgi?id=684618
We currently only keep track of old placeholders when moving past
the dragged app's current favorite position, as this is the only
case where we need to worry about jitter. Still, moving it into
_clearDragPlaceholder() allows us to consolidate code paths, which
is a good thing ...
https://bugzilla.gnome.org/show_bug.cgi?id=684618
The function currently only resets the placeholder position if
there is a placeholder; this is not necessarily true, as the
placeholder may be reset outside _clearDragPlaceholder().
If this happens, the placeholder will temporarily stop working
for the "old" position (and permanently if it's the only position).
Just reset the position unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=684618
Before, the text of those buttons were truncated when the text exceeded
the fixed width we had in the CSS.
Now, we give more horizontal space to the control buttons to match
the maximum text length of all buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=696307
Now that we control our own destiny, I noticed that getResultsToDisplay
is the only user of this._notDisplayedResult, and it's called immediately
after setResults, which is the only thing that sets it. Just remove the
stateness entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Since the provider icon only appears in the list results, it makes
sense for that to be stored with the results class, rather than outside,
triggered by which sort of display it is.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
It turns out that this focus code broke sometime in the 3.6 cycle --
when updating results, the focus is always on the text entry, so this
never gets called. We'll eventually replace it with something that
keeps track of the focused result meta, but for now, remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
While this is a very simple translation right now, soon enough it will
be so that it will have a less crazy "public" API and can do things like
cache result metas.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Since the two paths that call this want to keep the actor in two different
states, it makes sense to just call the one function that's the same between
both individually.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Right now, this doesn't give us very much, since IconGrid and StBoxLayout
have different APIs. But since we want to introduce result caching, it
makes to reduce the duplication we already have so we don't need to add
the code to do so in both places.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
pushResults, and the original async search API, were originally intended
so search results that weren't immediate could be added as they come in.
Since then, we've decided that the design of search results is that they
should finish at once with all results. Thus, the code was modified so
that pushResults always overwrote the current result set. As such, it makes
sense to rename the method so that the name matches the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=693836
Commit d0310bd745 blindly replaced global.overlay_group with
Main.layout.overviewGroup, but unlike the former, the latter is
hidden while the overview is not active, which makes it unsuitable
for the message tray's light box. In fact, with the removal of
global.overlay_group, there is no longer a container which may
be used both inside and outside the overview, so we can either
recreate the lightbox each time we show/hide the overview, or
use different lightboxes altogether; this opts for the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=701097
This is a singleton object inside libibus which means that if we
destroy it (e.g. because ibus-daemon got restarted) then, other
library users, like the ibus gtk+ IM module that we also use
in-process, will break.
https://bugzilla.gnome.org/show_bug.cgi?id=699189
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
Passkey is the proper name to be used when we are pairing with a Bluetooth
2.1+ device. PIN are only used for older devices which is not the case
here, the message is only shown when dealing with 2.1+ devices.
https://bugzilla.gnome.org/show_bug.cgi?id=697661
