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
Meta laters are invoked in reverse order of registration, so
having multiple laters propagating the geometry cause all but the
first one in the frame (which is usually wrong) to be ignored.
Instead, queue at most one later call, and use the last set geometry
in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=700853
In order to make sure that the struts and regions are initialized,
we need to make sure that we do with the conditions that nothing
is transformed, like the uiGroup, and that everything is visible.
These invariants broke during a fix to hide the UI until the
system background texture could be loaded. Now, reorder things so
that the system background is loaded, and then the UI is properly
loaded, and so on.
https://bugzilla.gnome.org/show_bug.cgi?id=696159
While the default style works well will a solid handle, using both
border and fill color would be desirable in classic mode. Add the
necessary (optional) style properties to allow this.
https://bugzilla.gnome.org/show_bug.cgi?id=697917
Instead of using the input mode, when the overview is not modal
it should use a Chrome-tracked actor, that is added to the input
region. Because the overview always takes pointer input when
visible, the actor is added at startup, and it is shown and hidden
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
If we are passed an invalid file template, ShellRecorder.record()
will return a %NULL filename; as the Screencast DBus interface
expects a string return value, we cannot return the value unmodified
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700842
Variable names like "sourceNotificationStackDoneShowing" are too
long, and too undescriptive: this one points to a source, not a
notification stack that has been done showing.
As the close button of folder popups overlaps at the top, it ends
up being cut off if the folder is located at the very top of the
view. Fix this glitch by taking the button's overlap into account
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
We already take care of growing the view if open folders overlap
at the bottom, however folder popups may still end up being cut
off when opening above the source icon - if the popup is high enough,
its y coordinate will be negative and therefore outside the parent's
allocation. To fix, we can either make sure that folders pop up below
their source icon in that case, or adjust the parent grid's position
as necessary while a folder is open. This implements the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
If the view doesn't fill the available space, content should still
start at the top rather than the center - not least the positioning
code for folder popups assumes that, so set the appropriate expand
flags.
https://bugzilla.gnome.org/show_bug.cgi?id=694371
The main overview actor was made reactive to catch scroll-events
and propagate them; after some code shuffling, the actor that
catches scroll events ended up not being the same actor that's
supposed to propagate this, which broke using the scroll wheel
to switch workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700595
Currently we show the workspace popup for relative targets ("up", "down"),
but not when targetting a specific workspace directly.
There is not really a good reason for that difference, and as we are about
to introduce a new shortcut to target the last workspace (which does vary
with dynamic workspaces), it makes sense to unify the behavior and always
show the switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=659288
Currently we stop monitoring application usage when disabling the
'enable-app-monitoring' setting, but we still expose previously
gathered data in the app picker's frequent view. This is not what
users should expect, so hide the view in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=699714
Some keyboard spot a dedicated search key, which gnome-settings-daemon
currently handles by spawning gnome-search-tool. It makes a lot of
sense to promote the Shell's integrated search feature instead, so
expose an appropriate DBus method g-s-d can use.
https://bugzilla.gnome.org/show_bug.cgi?id=700536
