SubMenuMenuItems close automatically with their parent, however
closing fails when the parent item is a MenuSection, as those
currently ignore any open()/close() requests.
At some minimal handling by emitting the 'open-state-changed' signal,
so children like SubMenuMenuItems work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=661029
PopupMenu.firstMenuItem returns a PopupMenuItem, not an apObj. We
need to retrive the latter using the _apObj property.
Also, somehow the property from the number of elements in a menu
was changed from .length to .numMenuItems, and this broke the
destruction of the menu upon emptying it.
https://bugzilla.gnome.org/show_bug.cgi?id=659277
Calling nm_access_point_get_ssid() in the handler of the
access-point-removed signal can result in DBus request, which will
then fail because the object was already removed at the server side.
Instead, use a difference function to retrieve the access point
object (the network), that compares directly by object identity.
https://bugzilla.gnome.org/show_bug.cgi?id=651378
Allow push_modal to optionally only work with a keyboard only grab and
use that in altTab as a fallback to allow switching windows while a pointer grab
is in effect (like during DND operations).
https://bugzilla.gnome.org/show_bug.cgi?id=660457
When two extensions monkey-patch the same area, enable() and disable() may
behave badly and completely wreck things. To solve this, when disabling
an extension, "rebase" the extension list so that monkey patches should be
added and removed in order.
https://bugzilla.gnome.org/show_bug.cgi?id=661815
Rather than loading and enabling all extensions at Shell init time, save some
time and gain some basic security by not loading extensions if they're
not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=661815
The GFileMonitor on ~/.gtk-bookmarks was block-scoped in the
PlacesManager._init() function, which caused it to be destroyed as soon
as the constructor was done. This caused changes in bookmarks to never
be notified to possible watchers (such as the places-menu extension).
To fix this, the 'monitor' variable has been promoted to an object
instance member.
https://bugzilla.gnome.org/show_bug.cgi?id=661921
When requesting a presence change, the actual presence set by
mission control does not necessarily match the requested presence
(if an active account does not support the requested presence),
which may result in the wrong presence being restored.
As a fix, be more cautious about saving status by assuming that
users do not request presence changes between an automatic presence
change request and the actual change.
https://bugzilla.gnome.org/show_bug.cgi?id=661485
Historically, when applications set "image-data" they expect it to show up
as an icon. So we display it as such if an icon is not specified with an
"app_icon" argument to Notify(). We also use "image-path" for an icon if
an icon is not specified.
We only display a large image specified with "image-data" or "image-path"
if an icon is also specified.
https://bugzilla.gnome.org/show_bug.cgi?id=659158
The message tray focus grabbing code sets the stage input
mode to Shell.StageInputMode.FOCUSED when the overview is
not visible. This ensures the stage window's input
region gets reshaped to include the notification chrome,
and so that input events get delivered appropriately to
the notification that grabbed focus.
The message tray code never tries to restore the stage input
mode later. Instead, the code relies on the stage input
mode (and input region) getting reset to
shell.StageInputMode.NORMAL automatically when focus moves
back from the shell chrome to a window in the user's session.
It's not really correct to set the stage input mode based
on the overview's visibility, though. At the login screen,
even though no overview is visible, the stage input mode is
Shell.StageInputMode.FULLSCREEN which is sufficient
for the notification's needs, Furthermore,
Shell.StageInputMode.FOCUSED is insufficient for the login
dialog's needs since the login dialog isn't considered
part of the shell's chrome and won't get included in the
stage input region.
This commit changes the message tray code to only set the
stage input mode if the current stage input mode isn't good enough,
rather than assuming the input mode isn't good enough just because
the overview is hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=660919
Because we were sorting the Alt+Tab list by user_time rather than
stacking order / MRU, it was possible for the currently-focused window
to sometimes not be the first app in the list. Fix this by using
meta_display_get_tab_list() to get the proper MRU ordering of windows
on the current workspace, and then convert that to an ordered list of
apps.
https://bugzilla.gnome.org/show_bug.cgi?id=645026
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
The current code uses the dash's height and current icon size to
calculate the new icon size. However, the height does not correctly
relate to the icon size while the icons are animating, in which
case the resulting icon size may be wrong.
Rework the function to be independent from the actual icon sizes,
so that a correct size is calculated even when called during an
animation.
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
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
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
This avoids unnecessarily removing and resetting the icon in the notifications.
This fixes the new chat notification sliding down and up slightly when new
messages are received.
https://bugzilla.gnome.org/show_bug.cgi?id=659768
Previously, when the avatar changed, we would not update the summary icon
for the source at all and would only update the notification icon when the
next message was received. Instead, we should update both immediately upon
recieving the signal that the avatar has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=659768
This code was never tested very well, and has several problems
currently (windows creeping down and to the right, windows snapping to
a different location after you move them). To be fixed in 3.4.
https://bugzilla.gnome.org/show_bug.cgi?id=659643
Clutter 1.4 had a bug where it would wrap when it wasn't supposed to, and we
were unknowingly relying on it. Explicitly pass the available width/height
to get a perfect allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=659633
While we allow for arbitrary modifiers in keybindings, both the
alt-tab and ctrl-alt-tab popups close when ALT is not present in
the modifier mask, resulting in ALT being de-facto hardcoded.
Instead, pass the actual modifier mask when invoking the popups.
https://bugzilla.gnome.org/show_bug.cgi?id=645200
Applying the "dim window" effect to the MetaWindowActor has two avantages:
first it avoids triggering bugs where ClutterOffscreenEffect doesn't handle
clone paint correctly. Second, it avoids showing the window as dimmed in
alt-Tab and the overview, which is weird.
The small downside of this is that the shadow becomes slightly gray when
the window dimmed, which is wrong - if we switched from blending with gray
to a combination of desaturation and darkening, this problem wouldn't
happen.
Revert out the addition of startY to the shader, since we don't need it
and fix the application of alpha, since we need to handle alpha correctly
for the shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=659634
When the active AP disappears, it is possible to receive the
"access-point-removed" signal before the "notify::active-ap" (as
dbus-glib + libnm-glib property notifications are not reliable).
In that case, we would remove the AP from the network object, thus
an attempt to update the UI would create an item for an empty
network.
https://bugzilla.gnome.org/show_bug.cgi?id=658150
Current code is sometime attempting to create menu items for wifi
networks that have no visible AP. I have no idea why this is
happening, but it should fix the symptoms and avoid exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=658150
The previous wrapping code hardcoded a width in pixels, making it
non-text-zoom-friendly. Specify a CSS width in pts, and fix the
userMenu code to completely opt out of the popupMenu column behavior.
Hack PopupComboBoxMenuItem slightly to deal with the fact that the
pop-up no longer gets setColumnWidth'ed.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
The keyboard status item doesn't derive from SystemStatusButton, since
it doesn't use an icon. But this meant it wasn't getting the right
class name, and so was using the full-width menu title highlight
rather than the small one. Fix that.
Currently entries' 'activate' signal is ignored, so hitting enter
does not have any effect, even if all required information has been
entered.
Instead, connect to the 'activate' signal so that hitting enter
behaves as if the "OK" button had been pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=659133
Currently network dialogs don't focus password entries, which means
that rather than entering their password directly, users first have
to click the entry (or tab around the dialog).
Instead, put keyboard focus on the first entry that requires user
input.
https://bugzilla.gnome.org/show_bug.cgi?id=659133
As dialog buttons used to "steal" the initial key focus, the polkit
dialog delayed focusing the password entry. With buttons no longer
overwriting the manually set focus, this is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=659133
ModalDialog provides a method to set the initial focus. However,
when adding buttons, the initial focus is always set to the last
button, thus overwriting a previously set manual focus.
Instead, only set the initial key focus if setInitialKeyFocus()
has not been called manually before.
https://bugzilla.gnome.org/show_bug.cgi?id=659133
