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
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
