The onscreen keyboard should not follow the locale's text direction,
but order keys according to the selected keyboard layout. Effectively
this means enforcing LTR on the keyboard actor.
https://bugzilla.gnome.org/show_bug.cgi?id=672024
We are currently taking "old" placeholders that are still animating
out into account to calculate the new placeholder position - this
causes an annoying bug, where dragging a dash item downwards triggers
quick continous position changes of the placeholder.
Just ignoring old placeholders fixes the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=651842
Some modifiers like NumLock or ScrollLock don't make sense in
keybindings, which is why we ignore them in mutter when matching
events to keybindings; for keybindings in the overview, we do
the matching ourselves, so filter the same modifiers as mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=665215
The hide animation causes hover notifications for the actors inside the
boxpointer. PopupBaseMenuItems, in particular, grab the keyboard focus on
hover notifications to enable keyboard navigation on menus. This, in turn,
breaks modal dialogs' keyboard navigation since key focus is taken away from a
just created dialog when the menu is hiding.
Since input events aren't useful while menus are animating we just prevent
them from propagating.
https://bugzilla.gnome.org/show_bug.cgi?id=662493
Checking if _buttonLayout contains _initialKeyFocus always fails since we
destroy all children before. Instead, use a signal handler id when explicitly
setting the initial key focus which is zeroed if/when the actor is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=663437
The dynamic-workspaces key was introduced to allow us to opt out of
writing the num-workspaces setting (which is ignored with the dynamic
workspace management anyway), but there'll be some expectations that
the setting will have an effect on the UI.
It's actually not very hard to support, so here's to the graybeards ...
https://bugzilla.gnome.org/show_bug.cgi?id=671568
With the recent keynav changes, the keyboard focus can now move
away from the search entry while a search is active. While we
keep the focus entry style while a search is active, we set the
cursor visibility depending on whether the entry has focus. This
doesn't seem very logical, so always request to show the cursor
when we appear focused.
Note that at least for now we are just expressing intent, as clutter
never draws the cursor for unfocused entries.
When canceling a search pressing Escape while the focus is on the
search entry we clear the entry, set its text to the hint and go back
to the previously selected tab. Make this the behavior also for when
the focus is on search results and not on the entry itself.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
Running apps are always kept in the dash, so removing them from
favorites just moves them to the end of the favorites list. This
behavior is not immediately obvious, so only show the remove target
when dragging a favorites application that is not currently running.
https://bugzilla.gnome.org/show_bug.cgi?id=644853
Saving the status to GSettings is pointless if it did not actually
change. If done during login, it is actually harmful, as it causes
dconf-service to be started.
https://bugzilla.gnome.org/show_bug.cgi?id=668214
When restoring the previous sesssion presence, we forcefully set
gnome-session's status. In the case of IDLE, this will trigger the
screensaver, which is clearly unwanted first thing after login. We
should only save and restore statuses that are explicitly set by the
user anyway, so limit presence saving to AVAILABLE and BUSY statuses.
https://bugzilla.gnome.org/show_bug.cgi?id=665701
Previously, PanelMenuButton would only set max width if the user
explicitly clicked the menu button, resulting in submenus without scrollbars
if opened via keyboard navigation or mouse over.
https://bugzilla.gnome.org/show_bug.cgi?id=658946
loadExtension() fails if the extension object is already created,
but the installation dialog was creating a dummy object in the
downloading state. Since nothing requires that (and the object is
not in the correct format anyway), just kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=671134
This hack was part of the custom scroll view code that allowed for
proper scrolling when the actor was near the screen edges. Since
the port to St.ScrollView, it's unnecessary and downright wrong,
causing portions of actors to be clipped. Remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=613194
If a widget isn't focusable or none of its children are focusable, then
navigate_focus will return false and the key focus won't be set. We
need to explicitly grab the key focus in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=671001
* Add a keyring prompter based on GcrSystemPrompter
* Adds dependency on gcr version 3.3.5 or higher
* Not yet using unmerged support for non-pageable memory
https://bugzilla.gnome.org/show_bug.cgi?id=652459
The preferred way to unmaximize/untile a window is by using a drag
gesture. Extend the available area to start this gesture into
non-reactive parts of the top bar above the window - with that we
take advantage of the "infinite height" of the screen edge, and the
extra space is particularly useful when the window has its titlebar
hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=666359
We were supposed to be updating the notification's title when the
window title changes, but we didn't actually bother to re-format
the title and body, effectively leaving the notification unchanged.
For modal dialogs without buttons, the button group still contributes
padding/spacing. To fix that, hide it by default and only show it
when actually adding buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=668209
The appSwitcher has been using a custom scrolling implementation because
St.ScrollView was buggy when it was written. The bugs have been fixed
so remove the custom implementation and move to St.ScrollView.
https://bugzilla.gnome.org/show_bug.cgi?id=613194
The old formula worked only when the primary monitor was positioned at the
top of the virtual desktop. When that was not the case, the available
space was miscalculated sometimes resulting in negative numbers, which in
the end produced strangely vertically stretched window thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=651130
Although not all "Finding and reminding" applications are ready
yet, the integration with gnome-documents' search results overlaps
enough with the "Recent Items" provider to justify its removal.
https://bugzilla.gnome.org/show_bug.cgi?id=670150
Allow applications to register search providers by dropping a keyfile
into a well-known directory. For now, initialize all found providers;
long term, we probably want to give users the ability to restrict the
set of active search providers.
https://bugzilla.gnome.org/show_bug.cgi?id=663125
Add an asynchronous search provider for results from a DBus service
implementing the org.gnome.Shell.SearchProvider interface; this
will allow applications to hook into the Shell's search without
implementing it in Shell itself or requiring an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=663125
We will allow applications to hook into shell's search by registering
a service which implements a well-known DBus interface.
"search-providers" is a reasonable directory name for applications to
drop their registration files, but it conflicts with "search_providers"
used by open search providers - rename the latter to avoid confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=663125
Currently, asynchronous search providers are expected to call
startAsync() in getInitialResultSet()/getSubsearchResultSet(),
which will trigger async mode until the search is canceled or
updated. Switching between synchronous and asynchronous mode like
this makes asynchronous search an implementation detail, but being
transparent to the searchDisplay means that certain optimizations
don't work as expected. Namely, updating asynchronous search results
causes flickering, and the automatic selection never focuses
asynchronous results.
So change the API to require providers being either synchronous (with
the current getInitialResultSet()/getSubsearchResultSet() methods)
or asynchronous (with asynchronous variants), and handle asynchronous
providers explicitly in searchDisplay.
https://bugzilla.gnome.org/show_bug.cgi?id=663125
renderResults() updates the results set, determines the number of
results to display, retrieves the corresponding result metas and
adds a new results actor for each meta.
Splitting the function in those parts allows to move the retrieval
of the result metas into SearchResults, which is where we ensure
flicker-free rendering and control the selection - we want to keep
both features for asynchronous result metas which we are about to
introduce.
https://bugzilla.gnome.org/show_bug.cgi?id=663125
Empathy uses to support 2 D-Bus API for calls:
- StreamedMedia: legacy API
- Call.DRAFT: experimental version of the new API
Since 3.3.90, Empathy only supports Call1, the first stable version of the new
API, so the Shell should do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=667694
Add a new dbus method that takes an area (x, y, width, height) and fires a
flashspot on it.
This would be useful for applications like totem and cheese.
https://bugzilla.gnome.org/show_bug.cgi?id=669660
An actor is removed from its parent after it emits the destroy signal,
so we can't just check if the notification stack has more than one
notification -- we need to check if there's a notification there
that is not the current one.
This was causing spew in the form of:
"this.notificationStack.get_children()[0]._delegate.setIconVisible
is not a function"
IconGrid items used to be square, so a single size value made
perfect sense. However, as contact search uses rectangular items,
using a single size is wrong - the allocated height ends up twice
the size of the visible height, which is particularly visible if
another provider displays results below contact results.
https://bugzilla.gnome.org/show_bug.cgi?id=670148
The correct way to make an actor having the same size as another is
a ClutterBindConstraint. Connecting to 'allocation-changed' fails because
the allocation might not change even when 'width' and 'height' properties do.
This is the case of Main.uiGroup, used as parent container for zoomed
window clones.
In lightbox.js we bind also the position because in principle it could change,
even if currently only fullscreen lightboxes are used.
VPN secrets are stored by the plugins, that provide separate
helpers for authentication. This commit adds the support for invoking
the binaries and pass them connection details.
For plugins that support it (as exposed by their keyfile), we invoke
them in "external-ui-mode" and expect a set of metadata about the
secrets which is used to build a shell styled dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
Substitutions generated by configure don't resolve prefixes, so
cannot be used for paths. Config already had localedir, and next
commit will need libexecdir and sysconfdir, so just bite the bullet
and move to sed.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
ConsoleKit is being obsoleted by systemd. Accordingly port the CK logic
in the gnome-shell automount manager to systemd-logind APIs.
This makes use of systemd-logind's native C APIs which are much easier
to use than the D-Bus APIs in this case, and much faster too (since they
are synchronous and directly query the kernel for the information we
need). The dependency is compile time optional, and in order to be nice
to the Debian folks g-s compiled with this enabled fill automatically
fall back to CK support on systems lacking systemd.
ConsoleKit is obsoleted by systemd-logind. Accordingly, port
the current CK code to systemd. In order to be nice to
the Debian people fall back to CK if systemd is not found,
so that the code makes the best of whatever it runs on.
Gsm.GetRegistrationInfo and Cdma.GetServingSystem return a single argument
consisting of a tuple, not three separate arguments. This is
a regression from the GDBus port.
https://bugzilla.gnome.org/show_bug.cgi?id=670005
Currently they return 'undefined' instead of something meaningful,
e.g. DND.DragMotionResult.CONTINUE. This was unnoticed because none
of the ancestors of the Activities button actors do any drag handling.
The only visible issue are JS errors generated when dragging, for example,
a window thumbnail over the button, because the cursor cannot be set.
https://bugzilla.gnome.org/show_bug.cgi?id=669921
Since the dummy actor occupies exactly the same area of the Hot Corner,
it can be erroneously picked during xdnd operations. Fix this by
hiding it from pick.
https://bugzilla.gnome.org/show_bug.cgi?id=669831
If both spacing and -shell-grid-item-size are 0, as they would be with nothing
setting them, we enter an infinite loop where we try to compute the layout.
Avoid the situation entirely by defaulting -shell-grid-item-size to a sane
value instead of 0.
https://bugzilla.gnome.org/show_bug.cgi?id=662747
The "extension" object is what I previously called the "helper" object.
It contains the extension importer object as well as the metadata object.
Things that were previously added on to the metadata (state, path, dir, etc.)
are now part of this new "extension" object.
With the new importer changes brought on by the extension prefs tool,
extensions are left without a way to import submodules at the global scope,
which would make them rely on techniques like:
var MySubModule;
function init(meta) {
MySubModule = meta.importer.mySubModule;
}
That is, there's now a lot more meaningless boilerplate that nobody wants
to write and nobody wants to reivew.
Let's solve this with a few clever hacks.
Allow extensions to get their current extension object with:
let extension = imports.misc.extensionUtils.getCurrentExtension();
As such, extensions can now get their own extension object before the
'init' method is called, so they can import submodules or do other things
at the module scope:
const MySubModule = extension.imports.mySubModule;
const dataPath = GLib.build_filenamev([extension.path, 'awesome-data.json']);
https://bugzilla.gnome.org/show_bug.cgi?id=668429
Add two new APIs, "launchExtensionPrefs" to let SweetTooth let the user
launch the extension preferences tool directly from the browser. To allow
SweetTooth to check if an extension can be configured, add a new key to
the 'metadata', 'hasPrefs', which is returned by the GetExtensionInfo/
ListExtensions DBus methods.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
A new tool, 'gnome-shell-extension-prefs' can load a new entry point from
extensions, 'prefs.js', which has an entry point to return a GTK+ widget.
This allows extensions to have their own preferences dialog, without each
extension needing to ship its own Python script and .desktop file.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
