Rather than relying on the caller to hide the remove target and
removed items before calling _adjustIconSize(), move that logic
into _adjustIconSize() itself.
https://bugzilla.gnome.org/show_bug.cgi?id=649248
In case _adjustIconSize() is called while the the dash icons are
animating, some extra work is required to yield the expected result.
Skip those extra steps when the icons are not actually animating.
https://bugzilla.gnome.org/show_bug.cgi?id=649248
Rather than relying on the caller to hide the remove target and
removed items before calling _adjustIconSize(), move that logic
into _adjustIconSize() itself.
https://bugzilla.gnome.org/show_bug.cgi?id=649248
Use ShellEntry.addContextMenu() to add context menus to most
existing entries, with the exception of:
- the login dialog - it may act be used to enter either the
username (e.g. no password entry) or the
password, and copy/paste does not make sense
(nowhere to copy from, nowhere to paste to)
- notifications - while adding a context menu is useful here as
well, it will require changes to the tray's
focus grab handling, so leave those entries
out for now
https://bugzilla.gnome.org/show_bug.cgi?id=659275
Add addContextMenu() to support context menus on right-click/long-press.
Depending on the parameters passed, the context menu only contains
"Copy"/"Paste" actions or an additional "Show/Hide Text" toggle action
for password entries.
https://bugzilla.gnome.org/show_bug.cgi?id=659275
While the ability to show the password can be useful at times,
the existing implementation is problematic:
1) The use of a switch is wrong (as even noted in a code
comment).
2) It is inconsistent with any other password dialog (login screen,
polkit).
In lack of a properly designed solution (for all password dialogs),
the designers agreed to remove the switch for now.
https://bugzilla.gnome.org/show_bug.cgi?id=658948
The keyboard hides prematurely when the user is typing into
an empty search box because the click is a captured event that
triggers a loss of entry focus. By adding a keyboard check to
this event, the problem is solved.
https://bugzilla.gnome.org/show_bug.cgi?id=661340
Currently BoxPointer/Menus always point to the center of the
associated source actor. This is generally what we want, but
add some API to adjust that behavior for the cases where it
isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=659274
Right now we show "(or swipe finger)" at the user login prompt
any time we detect a fingerprint reader.
Checking for the presense of a fingerprint reader isn't really
sufficient for knowing if it is appropriate or not to show the
message, though. Often, a user's fingerprint won't be enrolled
in the system even if the machine has a fingerprint reader.
In this scenario, we end up in a situation where the code will
fade out the message right after fading it in, or worse, fade
out the message while fading it in.
The former case looks flickery and bad, and the latter case
causes the login dialog to lock up since it never completes its
"show prompt" animation and we don't procede with the login
process until after that animation.
If a user is enrolled in the system, the fingerprint pam module
tries to tell the user to swipe their finger. We never show the
user that message because it's redundant with our own "(or swipe
finger)" message and because it uses techy words like "UPEK" and
"TouchStrip".
This commit changes the code to defer showing "(or swipe
finger)" until the fingerprint pam module forwards us its own
message. This makes it less likely we'll show the message when
fingerprint login won't work, and also removes the fingerprint
animation from the critical path "show prompt" animation.
https://bugzilla.gnome.org/show_bug.cgi?id=660492
Nvidia's twin view option does not align monitors properly, but with
a one pixel overlap. It looks safe to ignore an overlap this small
to make this case work.
https://bugzilla.gnome.org/show_bug.cgi?id=661387
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
Right-click menus in the dash can be dismissed by clicking anywhere
outside the menu. However, if a window clone is located beneath the
pointer when doing so, the window is activated and the overview
closed.
The cause of this unexpected behavior is that window previews are
activated on button-release, which is delivered to the preview after
the menu releases its grab on button-press. Use a ClutterClickAction
instead and let Clutter do the right thing, i.e. only trigger a
'clicked' signal when a button-release event is matched by a
corresponding button-press event.
https://bugzilla.gnome.org/show_bug.cgi?id=661151
tp-glib can sometimes emit a notify::alias signal when the alias doesn't
actually change. Bail out early instead of pushing an alias change message.
https://bugzilla.gnome.org/show_bug.cgi?id=660774
We now match individuals on other properties than alias, so take
this into account when representing a contact in search results
to avoid having them show up as "Unknown".
https://bugzilla.gnome.org/show_bug.cgi?id=660580
When workspace "previews" in the overview were just tiny gray
rectangles, it made sense to provide a way to move windows
directly between workspaces (by switching workspaces when dragging
a window to the corresponding screen edge). As the overview has
evolved however, the workspace switcher provides a good and
intuitive drop target already, so the alternative provided by the
screen edges is no longer necessary. As it also conflicts with
moving windows between monitors when using a vertical layout,
just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=660838
The variable |type| doesn't exist here; what we want to do is using the
first member of the contentTypes array instead.
Probably a leftover of some refactoring of the code I did while working
on this.
This patch fixes starting of the default application for a given content
type if the control-center panel is set to run it when a device is
plugged.
https://bugzilla.gnome.org/show_bug.cgi?id=660821
A boxPointer should be able to be attached to any actor, not just ones on the
primary monitor. Assume that the sourceActor doesn't straddle monitors, and
constrain the boxPointer to the monitor the sourceActor is on.
https://bugzilla.gnome.org/show_bug.cgi?id=659861
Originally the keyboard was initialized in the user-session-specific
code, but it was later moved to the generic code. Except that it was
accidentally copied rather than moved.
https://bugzilla.gnome.org/show_bug.cgi?id=659940
Devices are represented as susdut, not susbut (i.e. the percentage
is a double rather than a boolean) - apparently the wrong signature
works, but correct it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=660122
This ensures that this._clickedSummaryItem is always unset correctly.
Because we disconnect the signals that have _adjustSummaryBoxPointerPosition()
as a callback when unsetting this._clickedSummaryItem, we no longer call
setPosition() on this._summaryBoxPointer after it is hidden. Calling
setPosition() shows the box pointer again, which previously resulted in
an empty box pointer staying behind when a notification associated with
a tray icon was clicked.
https://bugzilla.gnome.org/show_bug.cgi?id=659862
Not doing so is considered as a bug as we don't accept the context right away.
It leads to tp-glib returning directly from the AddDispatchOperation() D-Bus
call and so automatically approve the channel if the Shell is the only
approver running.
https://bugzilla.gnome.org/show_bug.cgi?id=660084
