Stop pretending that VPN is a NMDevice, and split the useful bits into
a NMConnectionBased interface.
Make each connection have its own switch menu item and handle its own
status, and remove the VPN section title, which is no longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=682929
Currently the entry takes the intial key focus, but is not actually
part of the focus chain. Fix that, even though keynav does not work
too well for the dialog anyway, due to the entry consuming tab for
command completion.
https://bugzilla.gnome.org/show_bug.cgi?id=687127
When the user has the entered the password for the second time
and clicked OK, clear messages from the previous attempt, so any
new failure is shown clearly.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
Reposition the window overlay when the title changes, using the current
transformed size of the window clone.
Includes a test that changes title to a string of random length every 3 seconds.
Based on a patch by Alex Hultman <alexhultman@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=620874
While looking at how the plymouth implementation was built, I was so
short-sighted and focused on the string "_XROOTPMAP_ID" that I didn't
realize it was the name of the standard background on the root window.
Remove our own implementation, and switch to using a standard mutter
MetaBackgroundActor.
https://bugzilla.gnome.org/show_bug.cgi?id=682428
Rationale:
- Getting something out of the way should be quick;
- Very few things in the real world move linearly so, linear
animations, especially for something as big and visible as this,
felt too artificial;
- Moving the curtain out should start slower to make it feel like
having weight (it fills the whole screen after all) but quickly
accelerate towards the end to make it snappy too.
https://bugzilla.gnome.org/show_bug.cgi?id=686745
When the summary notification is open when the tray is closed, we end
up with two concurrent animations: the notification fading out, and the
tray moving away from underneath it. Sliding out the tray should be the
primary transition here, so hide the notification immediately to not
draw the user's attention away from it.
https://bugzilla.gnome.org/show_bug.cgi?id=686888
Having the close button move away from under the pointer after
clicking it is confusing and distracts from the main transition,
which is hiding the notification. Just hide it immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=682237
Rather than destroying the entire source, which is unintuitive, simply
close the notification. Removing the entire source is still possible
by right-clicking on the summary item and choosing "Remove".
https://bugzilla.gnome.org/show_bug.cgi?id=682237
GDM has a 'logo' key in its schema to allow distributors to add
some branding. It is currently placed above the user list, which
no longer works too well since the login screen lost its dialog
window. Display the logo in the top-left corner instead of the
Activities button instead.
https://bugzilla.gnome.org/show_bug.cgi?id=685852
Currently close() is a no-op when the menu has already been closed.
However, repeated calls could pass different animation parameters.
For instance in the user menu, we try to hide the menu immediately
before locking the screen, to avoid the popup jumping across the
screen while fading out - as we do this from the corresponding
item's activate handler, the closing is still animated if the menu's
own handler (which requests a full animation) is run first.
Fix this by changing close() to overwrite ongoing animations before
bailing out early.
https://bugzilla.gnome.org/show_bug.cgi?id=686484
Change the layout strategy to be more like the mockups. With less than
two rows of windows, we try to fit every window in a non-aligned situation;
with more than three rows of windows, we try to fit every window in an
aligned situation.
Based heavily on a patch from Pierre-Eric Pelloux-Prayer <pelloux@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=582650
Ouch. This went unnoticed for a long time as by default (using
dynamic workspaces) only one workspace is added at a time, which
happens to work fine.
https://bugzilla.gnome.org/show_bug.cgi?id=686487
Hide workspace switcher if dynamic workspaces is disabled and number of
workspaces is set to one only, since the user is bound to only one workspace
and showing the switcher is redundant.
Signed-off-by: Seif Lotfy <seif@lotfy.com>
The same logic as for commit 1f30670c1d applies to the case
where we lock the screen before suspending - we don't want the
menu to jump to the opposite screen side to fade out, so remove
the animation altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=686484
Due to a typo, it never worked correctly. After a fix-up to the appropriate
method, the behavior is suboptimal, as the buttons only fade in the first time
the modal dialog is constructed. Just remove the fade-in behavior, rather than
keeping this non-working code around.
https://bugzilla.gnome.org/show_bug.cgi?id=677426
This is a workaround for power users for the "Show Apps" button
placement being too inconvenient to press at the bottom of the
dash favorites list.
Unity also uses Super+A to show the Apps lens.
https://bugzilla.gnome.org/show_bug.cgi?id=685738
Currently the label for the show-apps button is only updated during
drag operations, so after an item is successfully dropped on the
button, the label will still read "Remove from Favorites".
Fix this by resetting the label on drag-end.
https://bugzilla.gnome.org/show_bug.cgi?id=684627
If esc is pressed twice in succession in the unlock dialog, the curtain
is cancelled, but the dialog is cleared after the first esc cancels it,
and it's not destroyed and recreated.
https://bugzilla.gnome.org/show_bug.cgi?id=685441
The interface was declared to take an unsigned integer instead
of a boolean, as gnome-screensaver does. Due to this,
gnome-screensaver-command --activate or --deactivate does not
work when used with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=686063
The configured calendar application might not actually be installed.
Instead of failing with an error message, hide the menu item altogether
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=686050
Since panel corners are currently square, this doesn't really affect much,
but it's very clear what the code was supposed to be. At the same time,
also fix up a redeclaration with 'let', which technically isnt' kosher.
If there are either no resident or persistent notifications, we'll
add some spacing for those boxes that may contain nothing. Make them
invisible to remove the spacing for those elements. It's possible
that we may want to be smarter about this in StBoxLayout to remove
spacing for zero-sized actors, but today is not the day.
https://bugzilla.gnome.org/show_bug.cgi?id=685919
Currently when the summary boxpointer is ungrabbed automatically
because the keyboard focus was moved outside the message tray
(for instance by selecting the overview search entry or opening
the right-click menu of a dash item), after the popup is hidden
_updateState() will grab focus and show the popup again.
Work around this by unsetting the clicked summary item when losing
focus to an actor outside the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=685156
Commit 448517032e added the message tray unconditionally to
the Ctrl-Alt-Tab popup, but while this makes sense for a normal
session, we do not want it in the login screen.
Be a bit more careful where we make the tray available.
https://bugzilla.gnome.org/show_bug.cgi?id=685914
This ensures that the desktop window's smooth fadeout when going to
the overview is in the same spot as the desktop window, which may not
always be at 0, 0.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
Having the tooltip change when it's visible looks strange and glitchy.
This also makes sure that "Remove from Favorites" doesn't change, even
when the user removes their mouse cursor from it.
https://bugzilla.gnome.org/show_bug.cgi?id=685313
The preference controls whether the screen should be locked when
the screensaver is activated, not whether the screen should be
locked at all. In particular after having switched to a different
user, log out should not automatically switch back to the unlocked
session, so always activate the lock when user switching.
https://bugzilla.gnome.org/show_bug.cgi?id=685536
Currently Return is used to activate the default button of a modal
dialog if no key is specified. It makes sense to allow alternatives
as the keypad's Enter key as well in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=685511
GDM does not allow concurrent logins of a single user, so making
'Switch Session' a user switch operation does not work - in order
to choose a different session, users have to log out.
Rather than making 'Switch Session' an alias of 'Log out' (which
is available anyway when multiple sessions are defined), remove
the item altogether - 'Switch Session' suggests an operation that
does not loose state, and we currently favor 'Switch Session' over
'Switch User', so on systems that have both multiple users and
multiple sessions, the latter would become unavailable.
https://bugzilla.gnome.org/show_bug.cgi?id=685062
Content-Type scanning can be super expensive. The autorun manager is meant
for local filesystems that are plugged into a USB port or similar, not
remote NFS or sshfs mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=684093
When Florian landed the new dash container to show the all apps button
always, he got the math wrong -- he forgot to add padding around the
container, and used the height of the box to calculate a y2 position,
rather than the y2 position of the box.
https://bugzilla.gnome.org/show_bug.cgi?id=684619
Currently the visibility of input volume is only updated when a stream
is added/removed - apparently no one noticed until now, as in the normal
user session we get away with this as long as we have some startup sound,
but this is not the case in the lock screen, so we may end up showing
input volume incorrectly.
https://bugzilla.gnome.org/show_bug.cgi?id=684611
The keyboard is shown/hidden automatically when (un)focusing a
ClutterText actor. This behavior is unwanted when opening the
extended keys popup, so focus changes to the popup are ignored.
However, we also want to ignore focus changes from the popup
to avoid the keyboard hiding itself after pressing an extended
key.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
The keyboard is shown/hidden automatically when (un)focusing a
ClutterText actor. This behavior breaks with the message tray now
grabbing/releasing key focus when toggled. Fix this by ignoring
all focus changes to or from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
Currently if a summary item signals that it has handled a click
itself, the tray hides itself. This behavior is wrong for the
On-Screen-Keyboard, which appears as a unit with the tray, so add
a property to opt-out of the default behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
GrabHelper automatically releases grabs when the user clicks outside
the grabbed actors. However at least for the message-tray (which is
the only user of grabHelper at the moment), we must ignore any events
from the On-Screen-Keyboard, to prevent the tray from hiding at every
key press.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
This fixes a case of _updateState() being called recursively,
resulting in stray grab()/ungrab() calls the leave the entire
desktop in a stuck focus state.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
The message tray is now modal and pushes the view up, but the keyboard
is shown below it. Solve this by applying a special styling to the
keyboard and message tray combination, and by not pushing the windows
up when the keyboard is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
When changing the user's avatar image, AccountsService will
overwrite the old image with the new one, so the location
returned by get_icon_file() is always the same.
In order to pick up the change, we need to make sure to clear the
previous image from both StTextureCache and StThemeNode's paint
cache.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
With the recent session mode changes, the visibility of settings
items is now only set on sessionMode::updated - while the signal
is emitted when the session mode is initialized, settings items
that are added after that are visible regardless of the allowSettings
setting until the next sessionMode::updated signal is received.
Fix this by explicitly setting the initial visibility of settings
items.
https://bugzilla.gnome.org/show_bug.cgi?id=684473
While the unlock dialog is created early so that it appears below
the shield while the curtain slides up, it is destroyed immediately
when the shield slides back in.
Keep it around until the shield is down instead.
https://bugzilla.gnome.org/show_bug.cgi?id=684342
When locking the screen, the user menu is moved to the opposite
side. Unless we close the menu immediately without animation, the
menu will jump to the other side and fade out while the screen
shield slides down.
https://bugzilla.gnome.org/show_bug.cgi?id=684343
Instead of leaving the login or unlock dialogs in an inconsistent state,
catch DBus errors and show an Authentication Error message. The error
details are logged in the session logs.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
Due to the way the IBus API works we might get property changes while
the menu is already open. In that case the separator visibility logic
doesn't work since it only applies on menu open/close. This works
around that issue.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
IBus has a properties API which are basically generic knobs into the
engine which are serialized and presented in a way that allows us to
easily build actionable UI elements with them.
Instead of implementing the whole generic system and accepting
everything coming out of the engines, for now, this patch just adds
support for a couple of important IBus Anthy properties.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
The screenshield requires gdm 3.5, which can be problematic in
jhbuild configurations, or distributions that don't use GDM as the display
manager. Allow transparent fallback to gnome-screensaver in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
When the tray is triggered by keybinding rather than dwelling, the
first summary item should be given key focus. Currently this is
achieved by grabbing the focus before toggling the tray, so that
the grabHelper will move the focus for us. However this interferes
with the grabHelper's focus save/restore mechanism - for instance,
after using the keybinding once, the tray will always come up with
the first item focused.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently it is only possible to use keynav inside the tray if it
has been triggered with the keyboard shortcut. Make it possible to
initiate keynav by hitting Tab in other cases as well.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently opening the summary boxpointer acts as a stop gap for
keynav - the only shortcut still working is "Escape" to hide the
tray altogether.
Change the handling of Escape to only close the summary boxpointer
and allow to use the down arrow as alternative (unless the boxpointer
already processes the key press itself of course, like the chat
entry does). Also add a Delete shortcut to dismiss the open summary
item.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently clicks outside the grabbed actors are handled the same as
the user pressing Escape - a single actor is popped from the grab stack.
However according to the design, outside clicks should release all grabs.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
When using keynav in the top bar, menus may be opened using the
down arrow; in a similar fashion, allow to open the summary
boxpointer with the up arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
'destroy' is emitted before the actor is unmapped during destruction, so
notify::mapped would emit an exception. Since unmapping is guaranteed,
the 'destroy' signal is unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=684154
Remove the PlacesManager, its search provider and all associated code.
Places search is now provided by nautilus using the external search
provider API.
https://bugzilla.gnome.org/show_bug.cgi?id=683506
When Dan Winship wrote the GrabHelper code originally, it didn't
handle a grab stack. I wrote the grab stack code hastily when landed
the message tray, not understanding all of the code that was involved
here.
Fix it so that we properly do the operations for each type of grab
when we first need to, and not sometimes when the first grab is taken.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
_hideTray() is called by _updateState() when the tray is visible
but should be hidden; however, _updateState() may be called again
from within _hideTray() when releasing the GrabHelper grab, so
unless we update the _trayState variable before that, _hideTray()
will be called a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
A couple of people have walked up to me and asked how to get to the
unlock screen from the screen shield. This was partly addressed by
bug 682285, but all three people who asked me about this said they
tried the return key and were surprised when it didn't work.
It sort of makes sense, since the user is "enter"ing the computer or
"return"ing to it.
This commit makes enter work in addition to the existing escape key.
https://bugzilla.gnome.org/show_bug.cgi?id=683889
Since we now use the capture phase to feed events into the input
method, we must set the capture flag for the event that starts
searches so that IMs can get at it.
https://bugzilla.gnome.org/show_bug.cgi?id=684040
If the user starts typing right away, assume that the entry is
for a password and don't clear it when the secret request actually
comes. Then, if the user completes typing, we also stash the answer
and send it to GDM right away on the first PAM prompt.
https://bugzilla.gnome.org/show_bug.cgi?id=681576
The onUngrab callback already checks if all notifications are destroyed and
hides immediately if so. Previous code instead would leave state handling
in an inconsistent state, by not removing the grab, not setting
summaryBoxPointerState to HIDDEN and not disconnecting various signals.
https://bugzilla.gnome.org/show_bug.cgi?id=684036
Look at the focus window's interaction timestamp to catch the case
where the user is typing and knocks the pointer into the tray or
mouses down to the bottom of the screen and clicks on something.
If the focus window's interaction time differs at the start and
end of the tray dwell then we don't activate the tray.
https://bugzilla.gnome.org/show_bug.cgi?id=683811
In gdm, we would attempt to become modal during the synchronous initialization,
and this would fail, as X prevents grabs on unmapped windows. Instead,
wait for the stage to be visible before becoming modal.
https://bugzilla.gnome.org/show_bug.cgi?id=683357
As PAM messages are now shown below the password entry, there is no
need for this complexity, and we can just hide all notifications.
Also, this avoids the ambiguity between notification.showWhenLocked and
source.showInLockScreen, which have very different effects.
https://bugzilla.gnome.org/show_bug.cgi?id=683369
The selector for insensitive popup menu items was wrong (a PopupMenuItem is
a ShellGenericContainer, not a StButton). Fixing it showed that previous
:insensitive tracking was manual for a reason: we have many items that are
not reactive, but don't want the insensitive styling (for example those in
the battery menu).
Fix it by adding a new style-class, popup-inactive-menu-item, that is added
to all new PopupMenuItems that are not activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=683988
CLUTTER_CURRENT_TIME (like GDK_CURRENT_TIME and libX11 CurrentTime) is 0,
and thus compares lower than all valid timestamps, meaning that
focus changes without an X11 event in the stack are ignored by
the on screen keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=664309
pending-messages-removed is emitted for sent messages too, but we don't
include those in the _pendingMessages list. Avoid useless spew in the session
logs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
St.Theme.load_stylesheet() does not queue a theme context change, so
any styling of widgets created before will not be updated. To fix this,
load the stylesheet before the extension builds its own UI in enable()
https://bugzilla.gnome.org/show_bug.cgi?id=682128
This means that right-clicking on an entry shouldn't visibly change the theme,
which is unexpected. Make sure that closing the menu refocused the entry, too.
https://bugzilla.gnome.org/show_bug.cgi?id=683509
When the dash contains more icons than fit at the minimum icon size,
icons are cut off at the end. This means that the show-apps button
will be the first to disappear, which is problematic given it's the
sole access point for other applications (for those that refuse to
use search at least).
Fix by using a dedicated widget for the dash actor, so that in case
of underallocation only icons above the show-apps button end up being
cut off.
https://bugzilla.gnome.org/show_bug.cgi?id=683340
Have distinct session modes for the lock screen and the unlock dialog,
and rework the logic in ScreenShield to have the lock-screen mode stack
onto the unlock-dialog mode (where applicable)
https://bugzilla.gnome.org/show_bug.cgi?id=682542
They are bigger and show an ellipsis if the count goes over 99. They
now have a blurred background and a drop shadow based on
data/theme/close-window.svg.
https://bugzilla.gnome.org/show_bug.cgi?id=682891
ClutterBinLayout is so amazingly broken: it uses the y_expand property to
find out if the children needs to honor alignment/fill, but that property is
"bubbled up" from the grand-children, so the notificationWidget would notice
the y_expand on the notificationBin (necessary to make the layout manager on
notificationWidget honor the alignment property for the bin), and would
receive the full height of the MessageTray actor from the parent's layout manager,
resulting in a notificationWidget shifting up, with the notification detached
from the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683628
The stage's background color can visible on screencasts when multiple monitors
with different resolutions are in use.
Change it to from blue to grey to look better as requested by the designers.
https://bugzilla.gnome.org/show_bug.cgi?id=683514
If the arrow's origin is so close to the edge that the arrow will not
be isosceles, we try to compensate as follows:
- We skip the rounded corner and settle for a right angled arrow as
as shown below.
|\_____
|
|
- If the arrow was going to be acute angled, we move the position of
the box to maintain the arrow's accuracy.
https://bugzilla.gnome.org/show_bug.cgi?id=680077
With the recent session mode changes, there is now a mix of modes
that are meant to apply to the entire session (specified as parameter
to the --mode command line switch) and temporary modes like the lock
screen; introduce a property to make the difference explicit, and only
allow "primary" modes to be specified on the command line.
https://bugzilla.gnome.org/show_bug.cgi?id=683488
Users of GrabHelper.grab() espect that the actor parameter (or one of its
children) will receive focus, irrespective of the previous focus location.
This fixes the key focus on the chat entry when expanding the notification.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
Hidden children are currently ignored in width requests; in the
case of submenu items, this results in abrupt width changes of
open menus when the corresponding SubMenuMenuItem is toggled.
To fix, only ignore SubMenu children when the corresponding
SubMenuMenuItem is hidden as well.
https://bugzilla.gnome.org/show_bug.cgi?id=683485
The special padding rules for submenu items currently ensure that
content aligns properly when the scrollbar is shown. While they
work nicely for the network menu, it looks odd for non-scrolled
submenus, so make this case explicit by introducing a :scrolled
pseudo class and adjust the style rules to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=683009
The code here was trying to center the label, but that didn't
happen because we allocated the entire space to the label, which
still plonks it at the top.
Message tray sources cannot be reused after destruction, so connect
to 'destroy' signal and clear out the previous one.
Also, fix some code paths that used the autorun manager incorrectly.
https://bugzilla.gnome.org/show_bug.cgi?id=683377
Previous code was activating the networkAgent and telepathyClient
in the lock-screen, irrespective of the previous mode.
Now it checks if the session mode is locked down, and if so it refuses
to start new components.
https://bugzilla.gnome.org/show_bug.cgi?id=683400
Previous code had a mixture of fixed positioning and ClutterBinLayout,
and this was broken badly for autorun notifications.
Rewrite to use ClutterBinLayout and Clutter properties exclusively.
https://bugzilla.gnome.org/show_bug.cgi?id=683378
Panel already forces each item to be a PanelMenu.Button, so it's better
to have the latter handle the bin container too, instead of attaching
a private property that might collide with internal usage by the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Previously we would only read the default sink and default source when
the connection to PulseAudio succeded. This worked because all VolumeMenu
users where initialized synchronously during shell load.
With the recent session mode changes though, the lock screen menu is
created on demand, and when it loads PA is already connected, so
it doesn't update the sliders.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Have main.js call .showDialog() when going back from the lock-screen, instead
of using the return value of createUnlockDialog to know if the dialog
was persistent.
_keepDialog is still used as LoginDialog cannot really be destroyed,
and cancelling it does not destroy it.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
The sudden transition from the lock screen to the user session
may be a bit sudden and overwhelming. Make ourselves more shell-like
by resizing out the screen shield according to mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=683170
It makes more sense to define session modes in terms of what you're
adding to the bare shell, not in terms of what you're taking away
from the user session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
If we don't freeze the presence icon, we can end up in a place where
we'll be updating the icon before we fade out the panel indicators when
coming back from the lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Components are pieces of the shell code that can be added/removed
at runtime, like extension, but are tied more directly to a session
mode. The session polkit agent, the network agent, autorun/automount,
are all components, keyring, recorder and telepathy client are all
now copmonents.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Instead of showing a notification, add a small message immediately
below the entry, and give the user two more attempts to login,
before going back to the welcome or lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
The supposed reason for launching the calendar server in a peculiar
way was so that the process would be killed when the Shell was killed,
but that didn't actually work. Launch the calendar server through auto-start,
and persist all throughout the session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Commit 5c6b1fd0c modified the hierarchy of SummaryItem contents, by
introducing a notificationStackWidget in place of the StackView, but
forgot to update the bits in ScreenShield.NotificationsBox that accessed
and reparented that directly, causing a crash by invalid theme node access.
https://bugzilla.gnome.org/show_bug.cgi?id=682683
We already could build the right part of the panel declaratively according
to the session mode. Extend that to handle the left and center parts.
Also, move the mapping from the roles to the classes in panel.js, as it shared
by all modes.
https://bugzilla.gnome.org/show_bug.cgi?id=682546
Ensure that all async callbacks check and ignore G_IO_ERROR_CANCELLED.
Ensure that all runs of authentication have their own GCancellable, so
that .begin() can be called multiple times on the same user verifier.
Check for fingerprint reader when beginning authentication, and not
when reset by GDM.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
Introduce a StShadowHelper to manage drop shadows from JS (which
cannot use Cogl directly), and use it in a new StWidget-derived
JS class to draw the arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
User testing has shown that it is not discoverable that the whole
lock screen can be dragged. A new mockup includes more arrows
and a short animation every 4 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
Legacy tray icons may want to take a pointer grab to show a popup menu,
and this is incompatible with message tray modality. To solve this,
escape the tray when forwarding clicks to the tray icons, and wait
for the input mode change to actually synthetize the X event.
https://bugzilla.gnome.org/show_bug.cgi?id=682244
This makes sense if we want to follow what the following comment says:
// We also want to keep it onscreen, and separated from the
// edge by the same distance as the main part of the box is
// separated from its sourceActor
Using a magic number violates the "separated from the edge ...
separated from its sourceActor" part.
https://bugzilla.gnome.org/show_bug.cgi?id=682343
Each summary icon is 48x48 with a padding of 6px on each side. Thus,
each summary item is 60px wide. Therefore the summary mode should be
60px high instead of 72px.
Changed the tray actor to use a ClutterBinLayout so that it honors the
y-expand property of its children.
https://bugzilla.gnome.org/show_bug.cgi?id=682248
Previously, when toggling a switch on we tried to replicate NM policy and
find a good connection to activate. This is broken in many situations.
Instead, only activate something when we can be sure it's what the user
wants (i.e. when there is only one connection, or when there is none,
and thus connecting will trigger the config dialog)
https://bugzilla.gnome.org/show_bug.cgi?id=683136
In multi-monitor setups, the screen might extend below the edge of
the monitor that holds the tray. In that case the tray is currently
triggered from a secondary monitor, which is rather surprising;
change the check to use the correct monitor geometry instead.
https://bugzilla.gnome.org/show_bug.cgi?id=683044
PopupMenuBase relies on open-state-changed to update the separator
visibility, but PopupMenuSection were only emitting when the parent
closed, so the first time the menu was opened, separator visiblity was
wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=682998
The design has a combined volume-network-power indicator in the lock
screen, which when opened shows a volume slider. Implement it by abstracting
the volume menu into a PopupMenuSection, and by creating three StIcons
bound to the real ones.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
The height of an unexpanded notification could include expanded
content if the notification has extra widgets (like actions and images),
so tweening to that cause it to expand visually.
Instead, use the height of the message tray before the restyle
as an upper bound.
https://bugzilla.gnome.org/show_bug.cgi?id=682738
Commit 22eea750 made info messages show up in the lock screen, but
as setShowWhenLocked() throws an exception when called on non-transient
notifications, the transient hint has to be set first.
https://bugzilla.gnome.org/show_bug.cgi?id=682268
Bumping overrides any animation, and causes the installed onComplete
not to run, which in turn breaks suspending from the user menu (as
it listens to lock-screen-shown).
Add a state variable (using an enumeration shared with messageTray)
to control the lock screen, and only bump when the lock is still.
https://bugzilla.gnome.org/show_bug.cgi?id=682746
Showing the removable devices is potentially a security risk (as
they include network shares). Also, a nautilus launched from there
can't be used, so it's just a way to overload the system.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
This makes the workspace indicator respect the "padding" style attribute.
Also, since we no longer draw the border on top of the thumbnail,
we need to be pixel-precise in allocating the indicator height.
We use this to make the workspace selector more similar to the mockup.
https://bugzilla.gnome.org/show_bug.cgi?id=662087
If the user has the mouse down - for example when they are selecting
text and dragging - then the attempt to get a modal grab will fail.
grabHelper: allow the .grab() function to fail and do nothing in this
modal case if the grab fails.
messageTray: handle grab failure and don't pop up the tray. Change the
logic for tray dwelling so that we only try to pop up the tray once
while the pointer is in the dwell area - this avoids the possiility
that the tray will pop up once the user releases the mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=682385
Currently we load all search providers from XDG_DATA_DIRS, so if
the same provider is installed several times in different directories,
we happily show duplicate results. To fix, keep track of all remote
providers we add and skip those that already have been loaded from a
different directory.
https://bugzilla.gnome.org/show_bug.cgi?id=682470
The app menu is hidden when entering the lock screen, however it
might be shown again while the lock is still in place - we don't
want this ever to be the case, so make show() a no-op while the
screen is locked.
https://bugzilla.gnome.org/show_bug.cgi?id=682475
AutorunManager relied on AutomountManager to find if the session
was active, and this broke when this stopped exporting a public
method for it. Fix AutorunManager to have its own reference to
the LoginManager.
https://bugzilla.gnome.org/show_bug.cgi?id=682455
Currently we animate scrolling to the active workspace both when
the number of workspaces changed and after changing the active
workspace. So in case we don't actually change workspace, this
results in an unnecessary animation that may even have unwanted
side effects: when done during the overview transition (e.g. in
the case of opening and activating a window on an empty workspace),
non-active workspaces become visible during the transition.
To fix, don't scroll to the active workspace when the number of
workspaces changes and rely on the 'switch-workspace' signal being
emitted as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=682002
Since dwell at the bottom of the screen is now the primary way of
summoning the tray, removing the hot corner to avoid having two
separate things that can be accidentally triggered.
https://bugzilla.gnome.org/show_bug.cgi?id=682310
Don't log a warning if an unrecognized device type is seen.
Don't show slave connections in the menu. (Eg, don't show the
individual wired connections making up a bond, since they can't be
used individually.)
Make the icon only reflect the status of connections that are visible
in the menu. (ie, don't show the "connecting" icon when an
unrecognized connection type is connecting, and don't show a
"connected" status if the only active connections are of unrecognized
types.)
https://bugzilla.gnome.org/show_bug.cgi?id=682364
The fingerprint message is useful for users that click their
names in the user list to let them know if fingerprint login
is available.
This same place on screen (below the login entry) can potentially
be used for other messages as well.
This commit changes the variable and style names surrounding
this feature to be more generic.
A subsequent commit will leverage this functionality to provide
a hint on how to log in to the local enterprise domain controller
(if relevant).
https://bugzilla.gnome.org/show_bug.cgi?id=681975
If the user leaves the mouse pointer at the bottom of the screen for a second,
open the tray. This simulates the eventual plan of measuring "pressure" by how
far the pointer is moved past the edge of the screen. Measuring pressure will
take X server changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682310
Right now, when entering the overview, we compute the window slots about
four or five times, from scratch each time. Move to a queued system where
extraneous calls to positionWindows don't matter.
https://bugzilla.gnome.org/show_bug.cgi?id=582650
Setting an IM presence only makes sense when connected to the
network, reflect this by making the presence chooser insensitive
when no network is available.
https://bugzilla.gnome.org/show_bug.cgi?id=677982
Trying to connect to IM servers while offline is pointless, in
particular now that we added a progress indication which makes
the connection attempt very visible.
To fix, wait for the network to become available until restoring
a previous IM presence.
https://bugzilla.gnome.org/show_bug.cgi?id=677982
The original code was assuming that getDay() on a Sunday would
return 7 rather than 0. This broke the "Next Week" logic
in several places.
This commit introduces a dayInWeek variable which takes the following
values on the according days:
weekstart = 1:
Mo: 0
Tu: 1
We: 2
Th: 3
Fr: 4
Sa: 5
Su: 6
weekstart = 0:
Su: 0
Mo: 1
Tu: 2
We: 3
Th: 4
Fr: 5
Sa: 6
Using this we can simplify and fix the conditional that decides
whether to show "This week" or "Next week" which was broken on
Sundays.
This commit also fixes the period that gets shown for "Next week"
on Sundays. Due to the bug it was 13 + 1 - 0 or 13 + 0 - 0 on
Sundays:
weekStart = 1:
saturday: saturday + 13 - day_in_week = saturday + 8 = sunday next week
sunday: sunday + 13 - day_in_week = sunday + 7 = sunday next week
weekStart = 0:
friday: friday + 13 - day_in_week = friday + 8 = saturday next week
saturday: saturday + 13 - day_in_week = friday + 7 = saturday next week
https://bugzilla.gnome.org/show_bug.cgi?id=682198
With the latest changes to the overview, the application view is now
clearly on a different level compared to the window picker. For that
reason it now makes sense to close it on Escape rather than hiding
the overview directly, as we do for search.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
Rather than relying on implementation details of StWidget's keyboard
navigation to "hide" the focusTrap from arrow key navigation, implement
the desired behavior explicitly in a custom widget.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
Tabs used to provide an abstraction for a page and the control used to
activate it. As the latter has now been replaced with external controls
handled directly in the viewSelector, the abstraction itself doesn't make
much sense anymore. In preparation of replacing it, move the search
handling provided by the SearchTab directly in the viewSelector.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
We pass the dash’s showApps button to the viewSelector, and we connect it
to the showing and hiding of the appsView. This is necessary because there
are different mechanisms for switching the views, and it has to stay in
sync with the button’s state.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
In the new designs, we no longer need favRemoveTarget. As it shares a lot
of its functionality with the new showAppsIcon, we refactor and restyle it
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
We’ll be repurposing the favRemoveTarget, which calls for it the be
permanently visibe. The favRemoveTarget used to be added to the dash when
needed and removed again when it wasn’t. This made that it always appeared
at the bottom of the dash. Now that we always show it, we also need to
explicitly define it to be at the bottom of the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
The entry should be positioned in the center of the overview. This makes
that its position can’t be set in the viewSelector without making things
overly complicated. Therefore we move the entry to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
Design calls for views being accessible by other means than the current tab
system, so we have no longer a need for the public viewTab API. Move the
initialization of tabs to the viewSelector and make
viewSelector.addViewTab() private.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.
https://bugzilla.gnome.org/show_bug.cgi?id=670168
This code was originally here to close the summary box pointer if it was
already open, but it seems that it isn't necessary, and is causing all
sorts of problems.
Displaying a close button provides a discoverable way to close notifications.
Clicking the close button on new notifications, dismisses them, but doesn't
remove the notification source from the message tray if it is resident.
Clicking the close button on summary notifications acts the same way as clicking
"Remove" option in the right click menu, which is to remove the notification
stack and its source, even if it is resident or a tray icon.
When we enter the overview, we don't explicitly don't take a grab, so we
shouldn't connect to key-focus-changed and things like that, otherwise
random overview code will drop our grab for us.
This fixes escape in the overview not dropping when a notification is up.
Make sure to account for modalCount properly, rather than just
tracking modalCount for the last actor on the stack. Additionally,
traverse the popped actors in the reverse order so that onUngrabbed
callbacks are called at the proper place in time.
If the user is already active when the notification pops up, we
won't get an idle watcher because there's no transition from
active to idle or vice versa. Correct this by initializing the
state correctly from XSync.
StScrollBar was intercepting motion events by using captured-event on
the stage, which required additional dirty tricks, which required
additional hacks. Simplify it by just using clutter_grab_pointer()
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=671001
The designers would like the message-tray to use different styles
depending on whether it is shown in the overview or not, so use
an :overview pseudo class as the top bar.
1) straddling windows get clipped at the monitor boundary
2) we move the bottom monitor and not the primary because that is
where the tray is
3) to stop the wallpaper from the bottom monitor leaking into the
primary, we adjust the clip as the clone animates up/down
https://bugzilla.gnome.org/show_bug.cgi?id=681392
The unlock dialog has a mechanism for manually typing in a username
and password. This mechanism is mislabeled:
Login as another user
when it should be labeled
Log in as another user
This commit adds the space.
Spotted by Stef Walter <stefw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=681750
Various code around had different paths for ConsoleKit and
logind. Consolidate it by making an abstract class that all
callers can use, which hides the implementation details of the
two daemons.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
Instead of manually tracking source icon changes, or requiring a manual
call to _setSummaryIcon, add a way to emit a signal when we're guaranteed
the icon has been changed, and then the source actor will automatically
update the icon.
_setSummaryIcon is still available for sources such as the notification
daemon, that require special treatment for the summary icon (to be used
with tray icons)
https://bugzilla.gnome.org/show_bug.cgi?id=680426
In preparation for accessing it in the screenshield, factor out
common code for ConsoleKit and Systemd.
Also, clean up ConsoleKit manager, as the daemon is required in
a non systemd installation. In particular:
- We allow it to be autostarted at session startup (or really,
we expect it to be already there, started by GDM during session
opening).
- We no longer silently assume that the session is active if
it can't start.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
In some cases can_focus value is taken directly as
!reactive. But this is not the case anymore, as
we are interested on navigate on non reactive items
https://bugzilla.gnome.org/show_bug.cgi?id=667439
We need to make sure the Source is fully constructed before creating
mainIcon, as SourceActor will query the count of the source.
This fixes Telepathy Chats.
https://bugzilla.gnome.org/show_bug.cgi?id=682045
Now that GDM no longer emits auth failures after 25 seconds, we
need to handle inactivity ourselves.
This has also the advantage that it tracks real inactivity, rather
than a timeout from a fixed point in time.
https://bugzilla.gnome.org/show_bug.cgi?id=682041
It doesn't make sense to have multiple ShellIdleMonitors, since
each has its own GDK filter function, but they all get the same
events. In preparation for having it accessed from other places
than the message tray, make it a singleton.
https://bugzilla.gnome.org/show_bug.cgi?id=682041
When pressing a key different from escape (one thus that has no
effect), bump the screen up, to indicate that it eats keyboard
input and it must be lifted up.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
This is a temporary patch. The user menu button needs to move to
the left, and the a11y menu in some cases needs to be hidden outside
of the screen lock too.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
Use the new monitor constraint to place the clock and notification
box on the primary monitor only. The background is still extended
to the whole screen.
Get rid of the LockDialogGroup hack, now that ClutterBinLayout
respects fixed position correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=681743
This commit makes ModalDialog use the new MonitorConstraint instead
of custom code to force itself on the right monitor.
At the same it ports wanda, which has something similar to a modal
dialog, but is not using the ModalDialog module.
https://bugzilla.gnome.org/show_bug.cgi?id=681743
Instead of connecting manually to LayoutManager, or using ShellGenericContainer,
make a ClutterConstraint subclass that can track automatically
a specific monitor index, or the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=681743
The fade animation we started using after centering attached
modal dialogs didn't work too well. So after going back to the
scale animation, adjust it to scale from the center rather
than the top, which works quite well.
https://bugzilla.gnome.org/show_bug.cgi?id=681601
The combination of desaturating and lowering the brightness does
not work too well in all cases, in particular for applications
using the dark theme variant. Dropping the desaturation effect and
making the brightness adjustment more profound gives a better
result.
https://bugzilla.gnome.org/show_bug.cgi?id=681601
Use the new OVERLAY_KEY keybinding action instead of special-casing
the overlay-key to make sure the same key will be used in- and outside
the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=665547
If automatic lock is disabled in the control center, only lock
when explicitly using the Lock menu item, and not for Suspend or
Switch user/session.
https://bugzilla.gnome.org/show_bug.cgi?id=680231
Rework the count system in Source, to distinguish between the
normal notification count and the count of unseen/unacknowledged
notification. (A notification is considered unacknowledged until
shown, as a banner or inside the summary box pointer).
Includes some code cleanups and a test for multiple notifications
in the same source.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
If a source is associated with an app, ignore the app name provided
by libnotify, as that is often garbage.
This fixes the "XChat-GNOME OSD" problem.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
Reduce padding around persistent sources, and ensure that spacing
around resident notifications is only applied once.
Also, add some padding to the clock.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
As description of the setting says, color-saturation ranges from
0.0 (grayscale) to 1.0 (full color), but the real outcome was the
opposite. The reason is that clutter provides a desaturation effect,
and color-saturation was passed directly to that effect. This patch
renames the effect and compute the desaturation value.
GetUserVerifier can only be called from the greeter session,
and fails with AccessDenied in all other cases. Also, calling it
hides the real error from OpenReauthenticationChannel, which
instead should be logged.
https://bugzilla.gnome.org/show_bug.cgi?id=680750
gnome-session and gnome-settings-daemon rely on the screensaver
interface to know the locked state. Since gnome-screensaver is no
longer running, it's up to gnome-shell to provide it.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
When the screen shield is activated from the user menu, animate
it instead of showing it abruptly. Also, ensure that the animation
had time to finish before calling UPower to suspend, to avoid
showing it when resuming.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Track screen lock status in the message tray, and filter banner
notifications. The message tray is completely hidden when the screen is
locked, but exceptions can be made for individual transient notifications,
such as shell messages and the on screen keyboard.
Non transient sources are shown in the middle of the lock screen. Resident
notifications (such as those from Rhythmbox) are shown in full, while
persistent ones are displayed as icon and message count.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Track locked status and use it to provide a reduced version of
the panel in the locked screen. Accessibility, input sources and
volume menus are preserved, without the link to the control center.
Network, battery and user menu are reduced to pure indicators,
with no menu.
This is similar to the design but not exactly, because designers
in IRC said that network needs more analysis before exposing, and
because the design didn't account for a11y and IM (so the one menu
metaphor is not really appropriate).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
The design calls for the curtain to appear in the gdm greeter too.
Implement this by having the screenshield manage the login dialog
(delegating its creation to SessionMode).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
This separates the screen shield into two main screens. One is
the lock screen, and it is shown when coming back from idle status
and when failing authentication. The other is the actual unlock
dialog.
Moving from the first to the second is possible by pressing Escape
or by dragging an arrow on the bottom on the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
This ensures that the screen shield is created at the right
stacking level, so the message tray is visible in the lock screen
(showing PAM messages, critical notifications and the on screen
keyboard)
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Ensure that the lightbox is above everything (including the screenlock
itself) when fading in - this allows for fading while showing the
unlock dialog. Also, don't pushModal again when already locked, or
we won't get out of it.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
When the screenshield is deactivated, instead of going back to the
session immediately, prompt the user for authentication.
This essentially reinstates what used to be provided by gnome-screensaver.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
We are replacing the gnome-screensaver module with with a screen shield
that is part of gnome-shell.
This patch fades out the screen on idle and shows a shield with a background
image when there is activity again. The shield can be removed with a key or
button press.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Add 'default' parameter to setButtons, that controls the binding
of Return (unless overridden) and applies the 'default' pseudo-class.
Currently it has no effect, but it will start having after the
login dialog redesign.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
To allow more than one summary icon actor for a source we split
the model of the source icon (which is iconName, if the default
implementation is used, or a GIcon otherwise) and replace
createNotificationIcon() with a generic createIcon(size). Also,
the actual source actor is split into a separate class, that handles
the notification counter automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
The :reactive property is used on StButton to like the :sensitive
property on GtkWidgets, that is, to indicate that the user is not
(yet) expected to click the button, and therefore should affect
styling too.
This allows to remove some code at the JS layer.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Previous code would access the array element before checking that
the index was within bounds, and therefore cause a TypeError.
It wasn't noticed earlier because at least one visible children
is in each panel box in all session modes.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Destroyed modal actors should be completely removed from the modal
stack automatically, including leaving modality if needed.
This allows for destroying modal dialogs without calling close().
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Change visibleInFullscreen to be trackFullscreen. If true, visibility
is fully bound to fullscreen status, if false, no change is made.
This allows to avoid set_skip_paint(), while not messing with
visibility of actors that are sometimes hidden for other reasons.
The flag was reversed because only the panel uses it, so false is
a more useful default.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Make it possible to control the visibility of "Show/hide text" item
at runtime, to reuse the same entry for both password and non-password
prompts.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
When GDM was moved over to GDBus it dropped the libgdmgreeter
library and introduced a new libgdm library with a somewhat
different API.
The main differences in the API are:
1) open_connection is now implicit and automatic
2) conversations don't need to be started explicitly, they're
started just-in-time when verification is requested
3) The functions are split up between the client, and new
helper objects that correspond to the dbus interfaces
they were generated from (one for user verification,
one for greeter specific operations, and a couple more
that aren't used by gnome-shell).
4) libgdm supports reauthenticating in an already running
session, so user switching should now affect the users
session more like screen unlocking does.
This commit moves the shell over to the new library.
Based on work by Giovanni Campagna <gcampagna@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=676401
As part of wanting to reuse some of the looking glass components,
don't use Main.lookingGlass, but instead pass the parent around.
Don't adjust the evaluator just yet, though. We'll split it into
a separate class soon.
https://bugzilla.gnome.org/show_bug.cgi?id=679944
This makes sense, since we are covering input methods and keyboard
layouts in the same keyboard menu. The effect of this change is that
the ibus status icon no longer appears in the system status area.
Changing the number of workspaces while the popup was visible (which
happens when moving windows on the last non empty workspace) resulted
in a wrong layout. Fix that, by listening to workspace-added and
workspace-removed signals, and by always requesting an updated size
from the actor.
https://bugzilla.gnome.org/show_bug.cgi?id=679005
We connect to the IBus daemon asyncronously and use it to query info
about input sources of the type 'ibus'. In case the daemon is or
becomes unreachable we just skip showing input sources of this type.
https://bugzilla.gnome.org/show_bug.cgi?id=641531
The calendar grid is build by giving each element right and bottom
borders, all top-most elements a top border, and all left-most
elements a left border. However in RTL locales, we currently add
the left border to the *right-most* elements, resulting in the grid
appearing clipped on the left side.
https://bugzilla.gnome.org/show_bug.cgi?id=679879
While modal dialogs were attached to the parent's titlebar, it
made sense to leave the top of the parent window at full color.
With the new position of modal dialogs, it makes more sense to dim
the entire parent window, so we can use a combination of Clutter's
BrightnessContrast- and DesaturateEffect instead of our own custom
shader.
https://bugzilla.gnome.org/show_bug.cgi?id=674499
With modal dialogs no longer being attached to their parents'
titlebar, the current animation no longer works too well. Use
a simple fade animation instead.
https://bugzilla.gnome.org/show_bug.cgi?id=674499
Show a notification when we receive a show-unmount-progress signal on
the mount operation we use for unmounting.
The notification will either turn fade out automatically with a
completion message when the unmount successfully completes, or will
disappear in case the operation is aborted underway (for example because
the device has been unplugged in the meantime).
https://bugzilla.gnome.org/show_bug.cgi?id=676125
When activating the app menu while displaying a startup notification
animation, the application shown in the menu does not match the
application providing the menu. To avoid this case, make the menu
button unreactive while playing the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=672322
This is a bare-bones copy/replace. It does not implement ChangeLog
support. If we cannot get System Updates integration, I will implement
notification support.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
When PackageKit signals that it prepared an update, offer an option
to reboot and apply it, using a helper that will setup the next
reboot and then calling to gnome-session.
https://bugzilla.gnome.org/show_bug.cgi?id=677394
This commit adds a grayscale effect to the magnifier, similar to
the lightness, brightness and contrast effects that are already there.
The effect is configured with the
org.gnome.desktop.a11y.magnifier.color-saturation setting, which
can take values from 0.0 (grayscale) to 1.0 (full color).
Based on a patch by Matthias Clasen <mclasen@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=676782
When connecting to virtual machines with usb-device redirection, such as Spice
enabled vms, automount may get in the way. Specifically if auto-usbredir is
enabled in the vm-viewer, then the usbredir code and the automount code race
for who gets to the device first.
If the automount code wins the race this is a problem, since usbredir causes a
device-disconnect (iow the usb mass storage driver sees an unplug), so in the
end usbredir always wins, and we end up with a non clean potentially corrupt
filesystem. Also see:
https://bugzilla.redhat.com/show_bug.cgi?id=812972
There for the need exists to be able to inhibit gnome-shell's automounting,
since all other inhibits run through gnome-session, I've chosen to do the same
for the automount-inhibiting. I've also submitted a patch to gnome-session to
reserve flag value 16 for this, see bug 678595.
This patch adds support to gnome-shell to honor this new inhibit flag.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=678597
The log messages about presence changes unnecessarily cluttered the
notification.
Instead, we now present the presence states (online, offline, away, busy)
with an icon placed right next to the avatar. We also no longer show
notifications on presence changes.
https://bugzilla.gnome.org/show_bug.cgi?id=669508
When selecting "Open Calendar" in the date menu, the configured
application is launched via command line, so we don't get any
startup notification. If Evolution is used as calendar application,
launch it via the .desktop file added by the last commit instead in
order to fix the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=677907
By disconnecting the 'notify::connection-status' signal as soon as the account
is disabled, we were missing the signal telling us when the status was moving
from CONNECTING/CONNECTED to DISCONNECTED and so the status icon was never
updated.
What we really want is to disconnect the signal when the account is removed
from the account manager as we don't care about it any more.
https://bugzilla.gnome.org/show_bug.cgi?id=669112
Use our native JS error system in the "extension system" API, only
using the signal/log-based error reporting at the last mile. Additionally,
delete the directory if loading the extension failed, and report the error
back over DBus.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Instead of using the 'extension-state-changed' signal to relay errors,
use DBus's native error mechanism to inform the method caller that the
call has failed. This requires making the method actually asynchronous
so that we don't block the browser, which is stuck waiting for a reply
from the browser plugin. To ensure this, we need to modify the browser
plugin API to ensure its extesion installation method is asynchronous.
Additionally, this lets us remove the awful, broken hacks that we used
when a user clicked the "Cancel" button, replacing it by a DBus return
value.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
When the extension downloader was originally designed, the information
downloading part was inserted at the last minute, along with the modal
dialog as a security feature to make sure an extension didn't silently
get installed on the user's machines either due to a security issue in
the browser-plugin, or an XSS issue on the extensions website. Correct
the mistake I made when writing the code; instead of dropping an error
on the floor, log it correctly. This "bug" has already bitten a number
of users who forgot to configure proxy settings in the control center.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Pam seems to give us different strings, sometimes 'Password:',
sometimes 'Password: '. Look for both of these when replacing
them with a translated prompt.
https://bugzilla.gnome.org/show_bug.cgi?id=675300
The current position below "System Settings" is problematic - the
items are unrelated, and misclicks will result in a scary system
modal dialog that has to be cancelled.
Move items around a bit to avoid this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=678887
Right now the "move to workspace" keyboard shortcut transition isn't smooth. It
shows the window disappearing, hopping to the next workspace, and then sliding
into view. "Pin" the window to the stage while the animation is in progress,
then release it afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=660839
Install a custom handler for move-to-workspace-* keybindings that
shows the workspace switcher, which gives the user a sense of
direction when navigating with the keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
Most of code implementing workspace switches was repeated with
minor differences on each direction. Instead, consolidate it
and use the new meta_workspace_get_neighbor.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
When using dbus-glib, single return values were special-cased to
be returned verbatim rather than as array with a single element.
This is no longer true since switching to GDBus, so fix the places
where the change was overlooked.
https://bugzilla.gnome.org/show_bug.cgi?id=678852
We strongly expect applications to use the same values for the
'Title'/'Icon' fields in their search provider .ini file as the
'Name'/'Icon' fields in their .desktop file. Rather than requiring
applications to duplicate those fields, allow them to specify a
'DesktopId' field instead to point to the corresponding .desktop
file, which makes it possible to ship search provider files without
translatable strings (which is nice given that merging translations
into search provider files lacks a standard rule).
https://bugzilla.gnome.org/show_bug.cgi?id=678816
Currently we pass an icon name for the 'icon' parameter of the
RemoteSearchProvider constructor. In hindsight, using a GIcon
instead will give us a bit more flexibility, so change it.
https://bugzilla.gnome.org/show_bug.cgi?id=678816
Use the ShellMountOperation dialogs we have to implement a DBus API
allowing other processes to display them.
Since GtkMountOperation now tries to call into our DBus implementation,
every application that uses a GtkMountOperation will gain integration
with our shell dialogs (but will still handle the actual communication
with GVfs).
https://bugzilla.gnome.org/show_bug.cgi?id=678516
Wait until the completion of the mount operation before dismissing the
passphrase dialog, so in case it fails, we can re-use the same dialog
with an error message (like e.g. PolicyKit auth dialogs) instead of
showing a brand new one.
https://bugzilla.gnome.org/show_bug.cgi?id=674962
Wifi and mobile broadband have signal indicators and are thus
more useful than vpn icons in the panel. Therefore, in the case
we have both wifi/3g and VPN we prefer the former as the "primary
icon" and add a lock next to it.
Behavior when VPN is added to wired or other connections is still
preserved: the wired icon is replaced by vpn.
https://bugzilla.gnome.org/show_bug.cgi?id=672591
Sorting by strength is what the other OSes do by default, and it
provides a better UX (by offering your hotspot and router before
the one from your neighbor).
https://bugzilla.gnome.org/show_bug.cgi?id=658946
Only apply the allowAutorun flag for transient notifications, not for
mounts that end up in the resident notification well.
Also, stop looking at volume.can_automount() here, since we already
checked that previously in the mounter, and allowAutorun is enough.
https://bugzilla.gnome.org/show_bug.cgi?id=660595
Previously, a volume was being ignored from autorun if one of these two
conditions were met:
- its mount root file had a native scheme and was mounted in a
non-hidden location
- it had a volume that could have been automounted, and had a flag set
by the shell to allow autorun
In order to effectively ignore volumes that we don't mount ourselves
from our notification system, we have to meet both conditions at the
same time instead.
https://bugzilla.gnome.org/show_bug.cgi?id=660595
This is a fallout from some changes in MessageTray.Source, which now
requires either defining the iconName/iconType properties on it, or
implementing createNotificationIcon, and we're not doing any of those.
Fix it by storing the gicon of the source object and using a helper
method to create the icon actor on demand, to avoid any case when the
same actor might be added twice to different containers.
https://bugzilla.gnome.org/show_bug.cgi?id=678428
The dependency chain spirals out from folks->zeitgeist->xapian...and
I'm really not interested in pulling in all of that into the core
shell.
There is work on splitting out contact search into gnome-contacts; I'd
add a bug link but Bugzilla is down.
When the shell takes control of the screen (for example to show
a modal dialog or to lock the screen), it must reestablish itself
on top of the stack, and in particular restore any unredirected
window so that it is composited below the Shell UI.
Reviewed-By: drago01 in IRC.
There is a race if a channel is invalidated during its preparation: the
'invalidated' signal is already emitted so the Shell will never notice.
We fix this by simply checking if the channel is already invalidated when
receiving it from telepathy-glib.
In the approving case, we reject the full ChannelDispatchOperation as we only
support approving one channel at the time.
https://bugzilla.gnome.org/show_bug.cgi?id=677457
Initially, extensions were loaded after they shell had fully created
the session and all objects, but this didn't allow extensions easy
ways to monkey patch prototypes, as most functions had already been
bound. Remove the historical vestigal function, and just merge the
two together.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
A large amount of extensions have something like this in them:
function init() {}
Since we have encouraged extension authors to try and not make any
changes in init, it feels weird and strange to have to create an
initialization function that does nothing. From now on, don't require
it.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
This allows us to move to a file-monitor based approach in the future.
Since we need signals, we convert the current set of functions to an
object we attach signals too, leading to the new ExtensionFinder object.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
We explicitly include NoDisplay applications in the ShellAppSystem because
we want app tracking for them, but we explicitly filter NoDisplay applications
out when showing them to the user because we don't want to show them to the
user. We also based our "All" apps view on a flattened list of apps. While
we did check for NoDisplay on the app item itself, we didn't check against
its parents. Refactor the app display view to not use a separate flat list
of applications, but instead a concatenation of all the applications in all
the loaded categories.
https://bugzilla.gnome.org/show_bug.cgi?id=658176
clutter_actor_get_children requires making a temporary GSList from
a linked list structure, and then creating a JS Array from that GSList.
For simple cases like the number of children, use clutter_actor_get_n_children.
https://bugzilla.gnome.org/show_bug.cgi?id=677426
Show the dialog on the monitor containing the pointer, rather than
the monitor with active focused window. This brings it inline with
the behaviour seen when launching applications.
Remove the focusMonitor/focusIndex from LayoutManager. These
properties were only used by the modal dialogs. Remove them since
they are not being used elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=642591
Don't show non urgent notifications when the primary monitor
is in fullscreen (user watching a movie, having a presentation,
playing a game ...).
Once the user leaves fullscreen show the messagetray so that the user don't
miss any notification (same as in "back from idle").
https://bugzilla.gnome.org/show_bug.cgi?id=677590
Do not overflow currentItems array. If the Menu section is filled
via model items-changed callback the position in the model passed to
the RemoteMenu _modelChanged can be a to be added asynchronously
action-added. Thus the item does not yet exists in the currentItems.
https://bugzilla.gnome.org/show_bug.cgi?id=676447
_startTimer adds a tweener to implement the description countdown, which
updates the entire content on each iteration, including the icon. This
causes a significant impact on performance, especially when accessibility
is enabled, as it causes a flood of AtkObject:state-change:showing events.
As the countdown only affects the description, factor out _updateDescription
and use it in _startTimer, and only do a full update of all contents when
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=674210
When displaying children, we need to make sure that we use the rowLimit
property that we pass to iconGrid, rather than assuming that it's
always MAX_SEARCH_RESULTS_ROWS in case some subclass (in an extension maybe)
wants to do something different.
https://bugzilla.gnome.org/show_bug.cgi?id=675527
Depending on the number of accounts, the type or simply the network,
there may be a noticable lag between setting the status and the actual
status change.
Use the new user-status-pending icon to indicate progress.
https://bugzilla.gnome.org/show_bug.cgi?id=659067
Refactor NMDeviceVPN to be more like the other NMDevices, including
having a valid getSectionTitle() and emitting signals when the
underlying connection changes state.
Use the existing notification infrastructure to hook these signals
to actual notifications (including some code consolidation).
https://bugzilla.gnome.org/show_bug.cgi?id=676330
Currently we only connect to the 'notify::n-workspaces' signal the
first time the overview is shown, which means we will miss any
changes to the workspace layout in the meanwhile.
In particular, the decision of whether the workspace switcher should be
shown is taken before the dynamic workspace handling takes over, and is
thus based entirely on the value of the num-workspaces user preference
rather than the actual number of workspaces.
Just connect the signal in _init() (with the nice side-effect to make it
explicit that the signal handler won't ever be disconnected).
https://bugzilla.gnome.org/show_bug.cgi?id=673198
role/label_actor should be used for the actor that will receive
the focus. In some cases it was also (wrongly) set on the
container, so using an AT like Orca, it exposed both.
https://bugzilla.gnome.org/show_bug.cgi?id=672242
It's used right away to discard some Empathy notifications.
This regression has been introduced during the 3.4 cycle when 'hints' has been
turned to a GVariant.
https://bugzilla.gnome.org/show_bug.cgi?id=675370
Ensure that the UI is updated when a connection changes name or id,
even if it was already known by a device.
Also, use less private properties on NMConnection objects, as they
can become stale and cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=677097
We now drop all status icons that are not explicitly enabled, which
breaks the ibus icon. Add it to the list of allowed icons until we
merge it with the keyboard one.
https://bugzilla.gnome.org/show_bug.cgi?id=677058
These methods were initially introduced when I was planning on having
an explicit DisableExtension/EnableExtension, instead of hooking up
a gsettings notify. This behavior was changed at the last minute, but
the methods were kept to avoid having to change the browser-plugin.
Consumers of this API should just set the GSettings key directly
instead now.
https://bugzilla.gnome.org/show_bug.cgi?id=676837
In Shell.SessionType.USER mode, two separate setup functions were
used during startup. With the new feature-based checks, the second
one is now almost empty, so move its remaining code into the first
function and remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Add a sessionMode.allowKeybindingsWhenModal property, which determines
whether keybindings should still be handled while a modal dialog is
up or not.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Instead of falling back to a set of default values or crashing the
window manager when an invalid mode is specified, check the value
of the ShellGlobal:session-mode property before taking over as WM
and make a clean exit if it cannot be resolved to an existent mode.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Rather than accessing global.session_type / global.session_mode
all over the place, delegate mode information to a dedicated
sessionMode object. While not very useful for now, we will replace
checks for a particular mode with checks for particular properties
that sessionMode defines based on global.session_mode.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Since commit 518282e169, we hide both "Switch User" and "Log out"
on single-user systems. However, if there is more than one session
available, users may still want to get back to the login manager
to change sessions.
Add both "Log out" and "Switch Session" items in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=675802
Bluetooth PINs are required to have 6 digits, so enforce that
condition by making the PIN request notification's confirm
button insensitive unless the entered PIN has the correct length.
https://bugzilla.gnome.org/show_bug.cgi?id=651251
The availability of a notification action may depend on conditions,
so add a method to control the sensitivity of buttons which have
been added with addButton().
https://bugzilla.gnome.org/show_bug.cgi?id=651251
When the appMenu is not available, for instance when no windows are
open (on the current workspace), we make its actor unreactive to
"hide" it from keynav. However the menu can still be triggered
erroneously when using the corresponding keyboard shortcut, so
add a check for the actor's reactivity there as well.
https://bugzilla.gnome.org/show_bug.cgi?id=676316
For most subclasses, this is a direct swap -- a lot of the time, the
constructor was a blank class that override createNotificationIcon,
and called _setSummaryIcon in _init.
https://bugzilla.gnome.org/show_bug.cgi?id=661236
Rather than ask most users of Source to subclass it to simply set their icon,
just allow them to create a new instance and add it without any complex magic.
https://bugzilla.gnome.org/show_bug.cgi?id=661236
Technically those are minor changes, but people will love us anyway:
- change the default of the <alt>ernative to "Power Off"
- remove "Online Accounts" item
- regroup the remaining items
- remove ellipses from labels
https://bugzilla.gnome.org/show_bug.cgi?id=675802
Now that all searches are async we can remove the code path for the
SearchSystem::search-completed signal which is no longer useful.
This patch ends up fixing the status text not being updated for when
there are no results.
https://bugzilla.gnome.org/show_bug.cgi?id=675328
As shown in the previous commits, synchronous search is easily implemented
by the asynchronous search API. The only reason we still have a
synchronous search API is of historical reasons. Well, we're not a museum,
and git log can keep our fossils safe if need be....
https://bugzilla.gnome.org/show_bug.cgi?id=675328
To allow this to happen, we need to make sure that we don't overwrite the
previousResults when calling the async method. Note that this is a bug of
some sort, we were already using this synchronous style when a remote
search failed.
https://bugzilla.gnome.org/show_bug.cgi?id=675328
On the code two labels are created. One is used on the date menu
itself, and the other for the menu icon at the top panel. The wrong
label was used as the label_actor for the top panel menu icon.
https://bugzilla.gnome.org/show_bug.cgi?id=675307
Pausing means that we will continue to use the same output file when
the keybinding is activated again. While useful to record a single
video in chunks, it doesn't seem to be how most users understand the
keybinding. Closing the recorder will close the file and create a new
one the next time the keybinding is pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=675128
Two nested scroll views were fighing with each other. The reason isn't
particularly important and has to do with some silliness involving
StAdjustment. The visible effect was that scrolling up and down when
in a summary item view would appear to be glitchy, and sometimes not
work at all.
To fix, make sure that the scroll view we don't care about is disabled
when in a summary mode.
https://bugzilla.gnome.org/show_bug.cgi?id=661615
There have been multiple notifications ever since we had a notification stack
per source, so the idea of one notification being on screen at a time has long
been dead.
https://bugzilla.gnome.org/show_bug.cgi?id=661615
We seem to have a lot of code that does something along the lines of:
if (condition)
actor.show();
else
actor.hide();
ClutterActor already has such a thing for exactly this purpose: the 'visible'
property. Use it instead of the mess above.
https://bugzilla.gnome.org/show_bug.cgi?id=672272
We hide the content around displaying new search results to prevent
flickering, unfortunately, one side effect of hiding an actor is
losing key focus if it currently is on the that actor or any
child. This could happen in the case of async results showing up after
the user had moved focus to the search results.
This patch works around that issue by saving the key focus and
resetting it back after displaying the new async results.
https://bugzilla.gnome.org/show_bug.cgi?id=675078
We already have one too many logging systems. Remove the errors tab
and make global.log/global.logError point to window.log/window.logError
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=675104
The keybinding to toggle the screen recorder was implemented as a
signal on MetaScreen, as keybindings could only be defined in mutter
core. As this is no longer the case, we can move the binding into the
shell where it belongs.
https://bugzilla.gnome.org/show_bug.cgi?id=674377
When receiving another message or responding in a new expanded chat
notification that has no prior chat history, the notification moved down
below the edge of the screen instead of expanding up, making part of it
invisible. Avoid this by making sure the notification's position is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=661944
A BindConstraint on the size of uiGroup forces full redraws of the scene.
Instead, implement and use get_preferred_width and get_preferred_height.
https://bugzilla.gnome.org/show_bug.cgi?id=670636
Commit 26580f8f reintroduced an optimization on style changes to avoid
creating icons unconditionally. As this breaks icon theme changes (for
instance when toggling "High Contrast" in the universal access menu),
remove it again.
https://bugzilla.gnome.org/show_bug.cgi?id=672941
nm_active_connection_get_devices() has a (questionable) special case
for the no devices case (which happens if the DBus object is
destroyed because NM went down): it returns null instead of an empty
array. Handle that instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=673043
With the application menu now being more than a stub, it has
become a much more interesting target, so add a keyboard shortcut
to open it directly.
This should also ease some of the pain for focus-follows-mouse users.
https://bugzilla.gnome.org/show_bug.cgi?id=672909
StBoxLayout currently does not handle height-for-width children
correctly under some circumstances. As a work-around, hard-code
a label height of two lines of text, which should work for most
locales in the one place the widget is currently used.
https://bugzilla.gnome.org/show_bug.cgi?id=672543
We currently require users to tab away from the search entry before
search results can be navigated using arrow keys. For convenience,
support using arrow keys directly from the entry.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
To avoid messing up St.Buttons' internal state with a pointer grab,
we wait for the pointer to leave the actor before starting the
drag operation manually. This works generally fine, but makes starting
a drag operation harder than necessary. To fix, enforce a reasonable
button state when starting the drag, rather than special-casing buttons
before the drag.
https://bugzilla.gnome.org/show_bug.cgi?id=637103
Currently, click and drop events are handled by each WorkspaceThumbnail
instance. With the introduction of the workspace cut and the request
to extend the reactive area of the workspace selector to the edge
of the monitor, it becomes more convenient to do all the event handling
inside ThumbnailsBox, even if this requires some manual layout computation.
https://bugzilla.gnome.org/show_bug.cgi?id=643319
Two small fixes which made _showNewStyleDialog() err out:
- g_key_file_load_from_data() expects a string as first
argument, but g_buffered_input_stream_peek_buffer()
returns an array of "data"
- g_key_file_load_from_data() is documented to allow -1 as
length parameter for \0-terminated strings, but the actual
type of the parameter is unsigned (d'uh)
https://bugzilla.gnome.org/show_bug.cgi?id=671556
Tweener uses a clutter timeline to manage all active animations
running at a given moment. The timeline is mopped up when no
animations are going any more.
Clutter requires timelines to have a finite duration, but since
animations can happen at any moment, no fixed duration can
accomodate the shell's needs.
To combat this problem, the tweener code picks a relatively
long duration: 1000 seconds. No string of animations should take
that long, so, in theory, that should be good enough.
Unfortunately, this tactic fails, in practice, when the user
suspends their machine, or VT switches. An animation can take
much longer than 1000 seconds (~16 minutes) to complete in those
cases. When the user resumes, or VT switches back the timeline
completes immediately (since it's already late) and tweener
never notices that the timeline stops ticking.
This commit changes the tweener timeline to automatically loop
back to 0 after completing, so that despite its fixed duration
property, it effectively never stops. Since the timeline loops,
its concept of elapsed time no longer increases monotonically,
so we now ignore it and track time ourselves with
GLib.get_monotonic_time().
This partially reverts commit
35764fa09e.
https://bugzilla.gnome.org/show_bug.cgi?id=653833
Some objects have a resolve hooks that throw exceptions, so just
checking "'actor' in object" can fail. In that case we should catch
the exception and return the standard toString() value, or the
object cannot be inspected from the looking glass.
https://bugzilla.gnome.org/show_bug.cgi?id=671410
We currently only update the status chooser's sensitivity if accounts
are added, removed or enabled; unfortunately during account creation,
the account may become enabled before it is actually valid, so the
status chooser remains insensitive. Fix by listening to validity changes
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=672265
Instead of duplicating the vendor prefix search in the endSessionDialog code,
just use lookup_heuristic_basename, which is used with real app tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=672270
gnome-session moved away from using properties over DBus in 2008, which
means that the code in GNOME 3.0 never should have worked -- but it did,
which makes me suspect that it was a quirk of the GJS DBus implementation.
Switch over to the proper inhibitor API, which is based on methods. If
gnome-session eventually gets ported to GDBus, then we can switch back
to properties.
https://bugzilla.gnome.org/show_bug.cgi?id=672270
Bailing out of _sync() early if the application lost keyboard focus to
the shell can only be done on actual application focus changes. In
particular, doing this check on a switch to an empty workspace while
the keyboard focus is already on the shell prevents the AppMenuButton
from being hidden as it should.
https://bugzilla.gnome.org/show_bug.cgi?id=672011
Reactive means that the actor is reachable from keyboard
navigation. If the target isn't current that means we are not tweening
the actor to be visible so we shouldn't set it reactive either.
https://bugzilla.gnome.org/show_bug.cgi?id=671998
If the user has their mouse over the workspace thumbnails while
entering the overview, it's more likely that it's a coincidence
that their mouse pointer is in the area. Avoid expanding the
thumbnails box in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=651092
In the workspace-collecting code we add a check to avoid collecting a
workspace if any startup sequence is running there. Since the sequence
can take some time to load, an helper function is also added which keeps
the (empty) workspace around for a very short time, while waiting for the
sequence to start.
https://bugzilla.gnome.org/show_bug.cgi?id=664202
If the user was inactive while a notification was shown, we show the summary
when the user becomes active again. This ensures that we inform the user of
the existance of new notifications that the user might have missed.
When the user comes back from away, the summary is now only shown if it has
new notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=643014
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
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.
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
ExtensionUtils is a new module that has a lot of miscellaneous things related
to loading extensions and the extension system put into a place that does not
depend on Shell or St.
Note that this will break extensions that have with multiple files by replacing
the old uuid-based importer with an object directly on the meta object.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
If an extension fails to import, we will pass the error object
to logExtensionError, which fails to pass it onto DBus as an
error object is not a string. To fix, convert the error object
to a string before passing it to logExtensionError.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
When the session status changes to IDLE, we automatically adjust
the IM presence; however, we should treat HIDDEN the same as OFFLINE
and not change the presence.
https://bugzilla.gnome.org/show_bug.cgi?id=642408
Since the port to GDBus, sessionActive is only set on DBus name
owner changes; this means that it may end up not being initialized
at all, and therefore always evaluate to false.
Make sure that the property is always initialized on startup.
https://bugzilla.gnome.org/show_bug.cgi?id=668020
gnome-settings-daemon commit 07b1ed63016 removed the custom 'Changed'
DBus signal in favor of the standard 'PropertiesChanged' signal, so
use that instead to update the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=667371
When the last window on a workspace is closed the focus goes to some other
window in another workspace which would cause us to show the AppMenuButton for
an application that isn't visible on the current empty workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=643867
Currently it is not possible to trigger the context menu while the
summary notification is opened (and vice versa). To actually trigger
the desired item, the user has to click again, which is annoying
without a good justification, so allow switching directly between
left/right click items.
https://bugzilla.gnome.org/show_bug.cgi?id=666197
Currently we display IM status information for every contact, falling
back to "offline" if the contact does not have an associated IM
account. Instead, don't show IM presence in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=662685
this.parent was ported from calling the parent class's method like
MessageTray.Notification.prototype._init.call(this, ...);. When
porting to Lang.Class, the 'this' parameter is now passed automatically, but
removing it was forgot in a few places. Fix these places.
https://bugzilla.gnome.org/show_bug.cgi?id=665017
We consider spacing and padding in _adjustIconSize, but as we use
the theme node from an actor which is not exposed to the CSS, we
miss the "real" values - correct this.
https://bugzilla.gnome.org/show_bug.cgi?id=662213
Clear the ClutterClickAction state before starting the drag,
otherwise it will eat the first button event after the drag,
preventing a new drag from being started.
https://bugzilla.gnome.org/show_bug.cgi?id=662386
Writting the screenshot to a file can take a relativly long time
in which we block the compositor, so do that part in a separate
thread to avoid the hang.
https://bugzilla.gnome.org/show_bug.cgi?id=652952
DashItem labels have initial delay before showing up, but once the
first label in the dash is visible (meaning the user is very likely
exploring things) and the pointer is moved along the dash, the label
will follow immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=666170
Signed-off-by: Seif Lotfy <seif.lotfy@collabora.co.uk>
- We should only call workspaceRemoved() for workspaces that are
are actually being removed.
- When we have multiple monitors, a window on a secondary monitor is
on all workspaces, so it ends up in all workspaces _allWindows
lists, so we can't use previous presence in that list to determine
whether we need to go ahead and add the actor; allWindows is simply
the list of windows where we are listening to notify::minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=667652
Since the application proxy is created asynchronously, at the time
the GActionGroup (GActionMuxer) is created, there is no GDBusMenu yet.
Defer creating the menu in that case.
Also, clear out signal handlers if have no target application.
https://bugzilla.gnome.org/show_bug.cgi?id=633028
We add a drag monitor to check whether the pointer is inside
the workspace selector, and update the visibility of the drop
placeholder consequently.
https://bugzilla.gnome.org/show_bug.cgi?id=664201
According to the GIO docs, sections can have labels too. We support
them by inserting a non reactive menu item at the beginning of the
section. This item is specially flagged to be ignored while processing
changed signals from the model (since it does not correspond to any
model item)
https://bugzilla.gnome.org/show_bug.cgi?id=666681
If there's a single small window (e.g. empathy chat) in the overview, it
looks usable, because it's as big as outside of the overview, but when
you start to type, overview search is launched, which is confusing.
Fix that by setting maximum scale for window clones to 0.7
https://bugzilla.gnome.org/show_bug.cgi?id=646704
In overview when closing a window and afterwards dragging a window it can
happen that you pick a wrong window or no window if windows' positions is
updated while initiating the drag.
Fix that by delaying window rearrangement when cursor is over a window.
https://bugzilla.gnome.org/show_bug.cgi?id=645325
DND code assumes it can query the size of the actor before parenting,
while StWidget asserts that get_preferred_size() is only called
after the actor is on stage. This fixes a crash while dragging
"Connect to..."
https://bugzilla.gnome.org/show_bug.cgi?id=633028
With GJS' GDBus implementation, we get the invocation paramters as an
array if we declare a method as async.
This is bad and not consistent with what GJS does for synchronous
methods, but it's the way it is, and other classes in gnome-shell
implement this correctly by exploding the array into its components in
the method implementation, but not the screenshot methods.
Also, we're supposed to return a value using the provided invocation
object, not with a callback now, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=667662
Commit 25948f214e replaced the old hardcoded scaling behavior of
background-images with the CSS-compliant option to control that
behavior with the background-size property. Fix some fallout from
the changed default scaling behavior.
That way different system notifications, such as the ones about battery power
and the ones about software updates, are shown with separate message tray
sources.
https://bugzilla.gnome.org/show_bug.cgi?id=664138
After an item is destroyed, all its signals were disconnected,
except for 'destroy' itself. This could lead to exceptions, if
destroy was called more than once on the item.
https://bugzilla.gnome.org/show_bug.cgi?id=665680
Instead of using an St.Tooltip to show the app's name under the icon,
manually position a new St.Label ourselves. Make sure to keep the label
hidden when right-clicking so it doesn't get in the way of the popup menu.
Only one tooltip/label will be displayed at a time.
https://bugzilla.gnome.org/show_bug.cgi?id=666166
GTK+ also exports window-specific actions, by putting the object path
for the exported action group in the _DBUS_OBJECT_PATH X property.
We add this action group to the app's muxer with a 'win' prefix,
since that is what the exported menu expects. Whenever the focus
window changes, we update the window-specific actions of its
application, and emit notify::action-group to cause the app
menu to be updated.
GDBusActionGroup api has changed again, adapt to that.
Also, use a GActionMuxer to add the 'app.' prefix to actions,
instead of manually stripping it out of the action names.
In the future, the muxer will also contain per-window actions
with a 'win.' prefix.
By the time the window is first mapped and the app menu button is
synced, we may not have finished reading the menu. In that case,
connect to notify::menu and update accordingly.
Use the new GApplication support in ShellApp to create the application
menu. Supports plain (no state), boolean and double actions.
Includes a test application (as no other application uses GApplication
for actions)
https://bugzilla.gnome.org/show_bug.cgi?id=621203
When transitioning from gnome-panel to gnome-shell in 3.0 we
lost the ability to summon the wisdom of the mythical fish.
This patch restores this, for the few adepts that are aware of
the magical incantation.
(Not as configurable as the original one, but it's an easter egg
after all...)
https://bugzilla.gnome.org/show_bug.cgi?id=666606
Forcing the icon size will distort it unnecessarily, and will
in any case not work if showing an animation (which is a ClutterGroup).
Instead, set the size on the bin, and make it align its child
if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
Previously the code in _accessPointAdded was iterating over the
the network list to find a good place, and at that time, added both
the network to the list and the item to the menu. When I refactored
to call queueCreateSection, I forgot to add code to insert the
network in the list.
Add it now, using the new Util.insertSorted function.
https://bugzilla.gnome.org/show_bug.cgi?id=666429
By using Main.queueDeferredWork, we can ensure that most of the
menu contents (in particular, the heaviest parts like the list of
wifi networks) are not updated immediately as we receive signals
from NetworkManager. Instead, the menu is rebuilt some time later,
or as soon as the user opens the menu.
This means that it is no longer needed to optimize for the
access-point-added case, replacing a lot of buggy code with a safer
call to _queueCreateSection, which in turn should ensure that the
more menu, if existing, is always at the end and that at most 5 networks
are visible outside it.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
We need to notify when the channel dispatcher calls HandleChannels on
us with a channel we already handle. However, we don't want to notify
if we claim a new incoming channel which doesn't actually have
anything interesting in it yet.
For example, a new channel pops up just to give a delivery
notification. We want (or, need) to handle it but don't want to notify
for it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=666243
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
The window overlays may be shown erroneously if hideOverlays is
called while the corresponding clone has an uncompleted tween which
calls showOverlays in its onComplete handler, for instance when
quickly leaving the overview before the initial overview animation
has finished. To fix, remove all existing tweens when hiding the
overlays.
https://bugzilla.gnome.org/show_bug.cgi?id=666020
When in overview, window labels flicker or are temporarily hidden on a
number of occasions - when simply clicking around the area the windows
are displayed in, dragging a window, sliding in the workspace list,
adding new workspaces etc. This patch makes the label for any window
visible at any given moment when in overview and the said window is
not being dragged around.
https://bugzilla.gnome.org/show_bug.cgi?id=644861
When wifi or wwan are blocked by hardware killswitch, we should not
allow changing the switch (it won't work anyway), and show
"hardware disabled" instead, similar to what we already do in the
bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=665194
When placing networks in _createSection, we were taking in
consideration that _activeNetwork is always first, by adding 1,
but then kept this offset also for networks following it (normally,
all of them, since _activeNetwork is also the most recently used),
that instead should not be affected by the movement.
This resulted in the menu showing 4 networks + More... instead of
5.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
The three boxes for the ripple animation are visible when created. This
means that the drag and drop code that searches for an actor to handle
the drag can find the ripple boxes instead of the Activities button or
hot corner. The latter can handle drag and drop while the ripple boxes
can't.
This is only a problem if drag and drop is attempted before the ripple
animation has been played: the boxes are made invisible at the end of
the animation. The fix is to just create the boxes invisible.
Instead of leaving the tray covering the whole last pixel row when it's
hidden, hide it completely. This avoids mouse events not being delivered to
application windows on the last pixel row.
To summon the tray we use a single reactive pixel on the corner.
https://bugzilla.gnome.org/show_bug.cgi?id=663366
The dash handles 'window-drag-cancelled', to be able to do the
animations for drag snap-back and size changes in parallel. As
the signal is not emitted for previews in the workspace switcher,
it does not work in that case.
If workspaces-only-on-primary is false, swipe scrolling is now
broken with multiple monitors. To fix, let workspacesDisplay
handle swipe scrolling for all views.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
If workspaces-only-on-primary is false, workspaces should be shown
on each monitor; rather than letting the existing workspaces span
the entire screen, manage one workspacesView per monitor (similar
to the extra workspaces in WorkspacesView when the setting is true).
https://bugzilla.gnome.org/show_bug.cgi?id=652580
Extra workspaces are special, in that they collect windows from
all workspaces for a particular monitor. This matches the default
behavior, but we need more than a single workspace per monitor if
workspaces-only-on-primary is false, so don't create the extra
workspaces in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
WorkspacesDisplay was introduced to manage the workspace objects
and views; however, the overview still accesses the view held
by the workspacesDisplay directly, which is a bit odd.
Add some additional methods needed by the overview, and make the
view a private property.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
When installing an extension at runtime, we accidentally swapped the 'type'
and 'enabled' parameters. While this doesn't directly affect anything right
now, as everything works coincidentally, future patches that look at the
'type' parameter to decide what to do would get the wrong answer.
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Third step in the class framework port, now it's the turn of
MessageTray.Source and MessageTray.Notification, as well as
the various implementations around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
No idea why connecting a key-press-event to a non-reactive actor
used to work, but some Clutter update broke it. Obvious fix is
to make the actor reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=664582
We prefer to ask the user for his own password. If PolicyKit
is not configured to accept that, try the root password. If
PolicyKit does not accept that either, ask for password of
the first user that PolicyKit _will_ accept. The last case
is a bit broken, but should rarely occur in real-life
configurations.
https://bugzilla.gnome.org/show_bug.cgi?id=651547
If no telepathy accounts have been set up or enabled, the IM status
chooser won't have any effect. To avoid confusing behavior, make
the status selector insensitive in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=662800
ComboBoxMenuItems use ClutterClones to reconstruct the active item
in the associated ComboMenu, so pseudo class changes due to state
changes of the ComboBoxMenuItem don't have the intended effect
(since the actual style information is taken from the associated
ComboBoxMenu item).
As a fix, propagate relevant pseudo class changes to the active
ComboBoxMenu item.
https://bugzilla.gnome.org/show_bug.cgi?id=662799
ComboBoxMenuItems use ClutterClones to reconstruct the active item
in the associated ComboMenu to not impose a particular MenuItem type
in the menu. However, this results in style changes (for instance
those triggered by icon-theme or text-scaling-factor changes) of
the ComboBoxMenuItem not having a visual effect until the ComboBoxMenu
is shown.
As a fix, force a style update on the ComboBoxMenu when the item's
style changes.
https://bugzilla.gnome.org/show_bug.cgi?id=662799
The option was merge with 'visual-bell-type' with the GSettings
port, but the change turned out too disruptive for the universal
access menu / settings panel, so gsettings-desktop-schemas commit
a5819b2a4e9 re-added the separate option.
- replace some left-over references to GnomeSession.Presence.setStatus()
- the correct replacement for GnomeSession.Presence.getStatus()
is *not* GnomeSession.Presence.connectSignal('StatusChanged')
This continues the series of patches for GDBus porting, affecting
all code that accesses remote DBus objects. This includes modemManager,
automount, autorun (for the hotplug sniffer), calendar, network (for
nm-applet only), power, scripting (for perf monitor interface)
https://bugzilla.gnome.org/show_bug.cgi?id=648651
Port org.gnome.ScreenSaver and org.gnome.SessionManager glue code
to use GDBus, and move /org/gnome/Shell/EndSessionDialog to the
GDBus connection, so it is backed by the org.gnome.Shell name.
https://bugzilla.gnome.org/show_bug.cgi?id=648651
Rewrite code acquiring dbus names so that it uses GDBus, and rewrite
ShellDBus so that it is exposed on the GDBus connection. Ports of
the other objects will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=648651
When changing _findNetwork with _findExistingNetwork, I changed
the return value to avoid searching twice for the access point,
and changed some names. I forgot to update all points where those
names were used.
https://bugzilla.gnome.org/show_bug.cgi?id=663278
Previously, we connected to notify::strength only if there was
already a signal connected, and the AP changed (thus, by induction,
we never connected). As a result, the icon became stale and different
from that shown inside the menu (which is correctly updated).
https://bugzilla.gnome.org/show_bug.cgi?id=650007
We must look for the actor under the pointer in the whole message tray and not
just in the notification. This will avoid us to capture focus when a
notification comes up with the pointer on the whole tray area.
https://bugzilla.gnome.org/show_bug.cgi?id=661358
Add "Mute"/"Unmute" option to the right click menu for chats to allow muting conversations
without blocking the sender or disabling all non-urgent notifications. Muting a conversation
prevents the pop up of notifications on new messages from the muted source, while these
messages are still available from the summary notification in the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=659962
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
A menu action may not make sense at any time, so add API to mark
an item insensitive to indicate that its action is currently
unavailable, but may become activatable at a later point.
https://bugzilla.gnome.org/show_bug.cgi?id=659270
Without this, the dim "fade" will start at the top of the untrimmed actor. With
a large enough draggable_border_width setting, this will show no fade at all.
https://bugzilla.gnome.org/show_bug.cgi?id=659302
The way the window dimmer shader is applied will cause rendering errors with
the rounded corners, invisible borders or shaped textures since it doesn't deal
well with the multitexturing used by the MetaShapedTexture. Use an off-screen
buffer to flatten the texture before being applied.
https://bugzilla.gnome.org/show_bug.cgi?id=659302
We don't want the tray bar to open/close quickly when adding a chat because
it happens when user opens the chat from Empathy. The notification will
popup on incoming message anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=657249
In a normal user session you can't have more than one
popup, because the popup is modal and we don't allow
the popup to show up when there are other modals.
In a GDM session, however, the login dialog is modal, and
we want a popup, so we don't have that same check.
This commit changes the ctrlAltTab manager code to not
allow multiple popups.
https://bugzilla.gnome.org/show_bug.cgi?id=659177
Users depend on being able to switch focus between the panel
and the login screen using ctrl-alt-tab.
Because the login screen has no overview, we were short circuiting
some code that needs to get run to support ctrl-alt-tab.
This commit changes the short-circuit code to only run for user
sessions.
https://bugzilla.gnome.org/show_bug.cgi?id=659177
Making users have to log in to power off the machine isn't a good idea.
This commit adds a power menu similar to the one in the fallback greeter
which offers 3 items:
- Suspend
- Restart
- Power off
https://bugzilla.gnome.org/show_bug.cgi?id=657822
While the current behavior of setting the IM status to "busy" while
notifications are disabled makes sense, as incoming messages are
very likely to be missed, it is not immediately obvious.
Display a transient notification to explain the behavior to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=652718
Simplify the layout in rightBox by getting rid of statusBox, and just
putting everything into rightBox directly.
Simplify the handling of the user menu by adding it like it was a
status icon rather than special-casing it. Rename the "tray_icon"
variables to "status_area" to reflect this better.
https://bugzilla.gnome.org/show_bug.cgi?id=651299
Legacy trayicons are mostly gone, so remove some of the special-casing
for them to simplify things.
Also, fix panel.addToStatusArea() to interpret its "position" relative
to tray_icon_order, not relative to the existing contents of
statusBox, so that the order that extension icons appear in does not
depend on the order they are loaded in.
https://bugzilla.gnome.org/show_bug.cgi?id=651299
The underline highlights on the panel menu items normally have a 100ms
transition between highlighted and unhighlighted, but the panel corner
graphics can't do that, so we hacked the Activities button and user
menu to have no transition. But in gdm mode, the user menu isn't the
rightmost item any more. Fix this by modifying the CSS from the code
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=651299
It does not make a great amount of sense to have this function
on the login screen. And worse, it does not work, since the greeter
is currently a modal dialog, so interaction with the opening
window is impossible.
https://bugzilla.gnome.org/show_bug.cgi?id=659164
The style of the top bar's corners is bound to the style of the
corresponding button; we used to hardcode this association, but
as the login mode does have a different layout, the button is now
determined programmatically.
Unfortunately, some containers take the text direction into account
when ordering their children, while some don't, so the current
code returned the wrong button in RTL locales.
https://bugzilla.gnome.org/show_bug.cgi?id=658983
Commit e5bc3a2ba8 changed the hierarchy of WindowClone, which
broke activating windows on hover during xdnd operations. To
avoid intrusive changes, just hide the new actor from picks so
that DND operations pick the actor actually meant to represent
the corresponding window.
https://bugzilla.gnome.org/show_bug.cgi?id=658640
Pop up a dialog when trying to install an extension so that users are aware
they are installing one. This is a security precaution in the case that an XSS
exploit has been found on the website, which could cause someone to inject a
<script> tag and silently install an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
libsoup won't check for a valid cert by default, so copy some logic from
glib-networking to check against the system cert list. Additionally, allow a
fallback for developers, ~/.local/share/extensions.gnome.org.crt, for easy
local development of the website.
https://bugzilla.gnome.org/show_bug.cgi?id=658870
For those who like their system pure, this provides the ability to purge a
pesky extension and its precious place on your disk space, and in your
"Local Extension" list.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
Conflicts:
js/ui/extensionSystem.js
This ensures that we don't show an animation of an empty blob being hidden when
clicking an action button causes the notification to be destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=658525
When the keyboard is configured, make lg shorter (if necessary) to
avoid overlapping it.
Also, make a few simplifications to lg's layout code. In particular,
move it into panelBox, to simplify its interactions with the panel.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The keyboard and tray need to animate together, but they sometimes
need to be in different stacking layers (eg, from the screensaver you
want access to the keyboard, but not the tray). So remove _bottomBox
and just keep trayBox and keyboardBox lined up manually.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Rather than having a single chrome layer and putting all of the chrome
into that, put the chrome actors directly into uiGroup, so that they
can be stacked independently of one another relative to other actors.
(This requires making uiGroup a ShellGenericContainer, so we can use
skip_paint to avoid painting non-visibleInFullscreen chrome when we're
in fullscreen.)
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The struts were being set while the panel was offscreen (starting its
slide-in animation), and then belatedly getting fixed the next time
something else caused a chrome update. Fix this by setting them before
the animation, and freezing them during the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Force an allocation at thumbnails creation so we can figure out whether we
need to scroll when selecting.
We also need to show() the whole AltTabPopup before calling _select() so that,
when computing the scrolling offset, the widgets already have their styles
loaded. Otherwise we will miss the switcher list item container's spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=655069
At least for the foreseeable future, the gnome-session desktop
presence won't be used for anything but suppressing (non-urgent)
notifications. To clarify this behavior, rename the "Do Not Disturb"
switch to "Notifications" (and adjust the switch logic accordingly).
https://bugzilla.gnome.org/show_bug.cgi?id=652718
This patch fixes the "apps vanish from alt-TAB bug".
If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...). In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.
In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.
What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance. This ensures we preserve any state such as the
set of open windows.
This requires moving the running state into ShellAppSystem. Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.
This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation. As long as
we're on top of random broken tar+wget wrappers, it will be gross.
A slight future improvement to this patch would add an explicit
"merge" between the old and new data. I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=657990
As extensions are now expected to provide a "disable" function,
they need to remove search providers they added. Implement the
removal functionality and add a public removeSearchProvider()
method.
https://bugzilla.gnome.org/show_bug.cgi?id=657548
We keep track of presence changes by connecting to the
Tp.AccountManager:most-available-presence-changed signal.
However, if multiple accounts are in use, telepathy may
lie to us and emit the signal even when the most available
presence is unchanged.
Work around this by keeping track of the current presence
ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=657703
Some search providers may want to change their results, or may not
want to block on an external service to get their results (DBus, etc.)
Set up an infrastructure to allow search providers to add their search
results at a later time.
Based on a patch by Jasper St. Pierre and Seif Lotfy.
https://bugzilla.gnome.org/show_bug.cgi?id=655220
This adds contacts search to shell, powered by libfolks.
Changes:
- Add Folks and Gee to the build system
- ShellContactSystem, a backend in C
- ContactDisplay, search frontend in JS
https://bugzilla.gnome.org/show_bug.cgi?id=643018
The current user status menu allow to set the session status,
which also influences the IM status when signed in with
mission-control. However, the way it is presented to the user
makes it hard to figure out how the statuses interact or that
there are two distinct status in the first place.
Therefore, use a separate control for each status, and update the
overall look to match gnome-contacts.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Given that our menus contain at most two columns, all switch widgets
in menus end up in the last columns, and thus aligned with the right
menu edge.
However, the updated user status menu will contain a section which
ignores the menu's column layout, so the switch might end up in
the middle of the menu if the overall width is determined by said
section.
At least for now, we always want the switch to align with the end,
so just expand switch menu items rather than adding an option.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Introduce a new menu widget, which displays the active item from
a set of options, and pops up a child menu to allow changing the
active item when activated.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Allow opening a popup menu from another menu. While the child menu
is open, events on the parent menu are blocked. The parent menu
is kept open when the child menu is closed; the child menu on the
other hand is closed with the parent, e.g. when the focus moves
to another toplevel menu.
This feature will be used to implement combo box menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
We haven't actually been calling the top-right menu "status menu" for
quite some time, so use the upcoming code changes as an excuse for
renaming it to "user menu".
Doing this rather than overdrawing a black rectangle saves us
(pixels in screen) * 8 bytes of memory bandwidth for every frame we draw going
into the overview.
It also allows us to dim the background on non-primary monitors making the
overall overview appearance consistent across all monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=656433
Instances of this class share a single CoglTexture behind the scenes which
allows us to show the background with different rendering options without
duplicating the texture data.
https://bugzilla.gnome.org/show_bug.cgi?id=656433
This commit adds GDM session support.
It provides a user list that talks to GDM,
handles authentication via PAM, etc.
It doesn't currently support fingerprint readers
and smartcards.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The shell has a number of things that are only relevant for
logged in users (e.g. calendar events, telepathy integration, a
user menu, etc).
This commit moves those user session specific bits into their
own functions in preparation for making the shell code ready
for use at login time.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Right now the panel code makes the left corner sync up with the
activities button and the right corner sync up with the user menu.
This is fine as long as we have an activities button and a user menu.
The login screen won't have those things, though.
This commit changes the panel corner code to try to figure out which
interface element is the most appropriate to sync up with based on
its position in the panel.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Images are part of the notification spec, so we should support them.
Marina Zhurakhinskaya provided some code for getting the layout right
for this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=621009
Have LayoutManager automatically deal with sizing and positioning
boxes for the panel and messageTray relative to the monitors.
Also, now that LayoutManager knows exactly where and how tall the
panel and tray are, have it manage the pointer barriers as well.
https://bugzilla.gnome.org/show_bug.cgi?id=612662
A modal dialog in the shell blocks anything but that dialog from
receiving user input. Applications within the session and other
parts of UI are rendered non-reactive.
When GDM gets changed to use the shell for its greeter, the user
list will be presented as a shell dialog. That dialog shouldn't
block access to the panel menus, etc.
This commit adds a shellReactive property that makes the ModalDialog
class continue to block access to applications, but allow the user
to interact with the shell itself.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The control-center contains user-pertinent settings
panels. These panels don't make sense to show outside
of a user's session, so hide them for session types other
than SessionType.USER.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
We're not going to want an overview at the login screen,
but a lot of code in the shell depends on the overview
existing.
This commit adds a new isDummy constructor property to
allow creating the overview as a non-functional, stub object
that doesn't do anything visible.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The dash object is currently exposed as a public object.
It's only used outside of the overview for the dash object's
iconSize property though.
This commit makes the dash object private and proxies the dash
iconSize property to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Right now, when a user clicks on the panel clock, a menu pops up with a
calendar and a list of events from the user's schedule. The list of
events only makes sense from within a user's session, however.
As part of the prep work for making the shell a platform for the login
screen, this commit makes the events list optional.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The theme currently hard codes the minimum size of the calendar
menu to make sure there's a designated area for events
(even if there isn't anything currently scheduled).
A side-effect of the hard coded minimum width is that
if the events area is hidden, the menu ends up much
bigger than the calendar. We don't currently ever hide
the events area, but we will in the future.
This commit moves the min-width restriction from the menu
specifically to the events area.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
The chrome layer contains the user interface elements (e.g.,
the panel) that disappear when fullscreen windows get displayed.
Panel menus are currently put in the chrome layer, but don't need
to be, since they are only displayed when the user is interacting
with the shell and not a fullscreen application.
Putting panel menus in the chrome layer does mean they will get
stacked below shell interface elements that aren't in the chrome layer,
though.
This commit changes panel menus to be on the same layer as most other
shell elements, so they get properly stacked above those elements.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Right now, if buttons get set on a dialog after it is mapped,
they just pop in instantly.
We shouldn't have any harsh transitions like that, though.
This commit changes the buttons to quickly fade in, instead.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
All the system status menus in the panel offer a
menu item to jump to a relevant part of the
control-center.
This means each status icon has the same, or nearly the
same bit of code to:
- Add a new "action" menu item and listen for its activation.
- Hide the overview if it's showing when the menu item is activated
- Find the relevant control-center panel from its desktop file
- Launch the control-center to the relevant panel
This commit consolidates all those details in a new method,
addSettingsAction. This refactoring reduces code duplication and
slight inconsistencies in the code resulting from that duplication.
It will also make it easier in subsequent commits to hide settings menu
items when the shell is used in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
A separator only makes sense if there are items on both
sides of it. There is quite a lot of code written
throughout the shell that manages the process of showing
and hiding separators as the items around those separators
change.
This commit drops all that code in favor of changes to the menu
implementation to dynamically hide or show separators as
appropriate, so the callers don't have to deal with it.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Wireless and 3g dialog code has moved to gnome-control-center, so
we can stop calling out to nm-applet. Also, we can now enable the
notifications provided by the shell and kill a bit of code about
auth that is not actually needed.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
Using the new ShellNetworkAgent, show a system modal dialog
(similar to the PolicyKit one) when NetworkManager needs secrets
for connecting to wireless.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
The order of indicators depends on the order of calls to
Panel.addToStatusArea. To have it consistent across enabling and
disabling of extensions, we need to place the core ones first.
https://bugzilla.gnome.org/show_bug.cgi?id=653205
This way all standard indicators have a shell implementation
provided, which prevents issues with extensions enabling/disabling
(in particular with xrandr-indicator)
https://bugzilla.gnome.org/show_bug.cgi?id=653205
Extensions often want to add items to the system status area, so it
is useful to add a convenience API for it. Also, we now allow
for cleaner destruction of panel objects, by just calling destroy()
on it.
Based on a patch by Jasper St. Pierre.
https://bugzilla.gnome.org/show_bug.cgi?id=653205
The "id" variable was being sporadically reset to null, and as far as
Florian and I could determine, this is actually a Spidermonkey bug.
The issue has something to do with:
1) use of "let" for the variable
2) Nesting a dynamic closure inside of a for() loop
Work around it here for now - I tried to create a minimized test case
to hand to the Spidermonkey developers, but failed. A big part of
the problem is it's only sporadically reproducible.
Direction containers group all contiguous messages in the same direction into
their own parent container, allowing for smarter styling of similar messages.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
This adds a new DBus method: InstallExtensionRemote(uuid : s, url : s)
Pass it the UUID of an extension and the URL of a manifest file: the same as a
metadata.json, but with a special key, '__installer', which is an HTTP location
that points to an zip file containing the extension. The Shell will download
and use it to install the extension. In the future, the manifest file may be
used to automatically detect and install updates.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
The two similar keys were hard to manipulate to have specific effects, so just
remove one. Now there is an *explicit* whitelist: all extensions must be in the
'enabled-extensions' for them to be loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
It's generally more useful to see when a person sent a message instead of when
we received it. Also, a recent change in Telepathy made the received timestamp
be 0 for messages we send.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
Adds methods to shell_global to allow taking screenshots
save the result into a specified png image.
It exposes three methods via shellDBus applications like
gnome-screenshot:
*) Screenshot (screenshots the whole screen)
*) ScreenshotWindow (screenshots the focused window)
*) ScreenshotArea (screenshots a specific area)
https://bugzilla.gnome.org/show_bug.cgi?id=652952
It is not possible to connect to hidden access points without
knowing the SSID, and it should be done using the control center
panel and the appropriate dialog. At the same time, this should
fix some warnings from libnm-glib and dbus-glib.
https://bugzilla.gnome.org/show_bug.cgi?id=646454
The shell should only notify in case no other client handles the message.
Empathy will ack the message if focused, so we don't want to step on its
toes.
Use the existing setting
org.gnome.desktop.default-applications.office.calendar.exec
as calendar application instead of the hard-coded evolution. Evolution
is still the fallback if that setting is cleared (it defaults to
evolution).
https://bugzilla.gnome.org/show_bug.cgi?id=651190
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Add a helper function (mostly copied from gtkcalendar.c) for getting
the first week day for the current locale, using nl_langinfo if
available and falling back to the GTK+ gettext fallback otherwise.
Use that function in the calendar, so that the LC_TIME setting is
used if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=649078
Instead, create three ripples and keep tweening them. This gives a dramatic
speedup when entering the overview, but means that we can't have the same animation
running twice. In this case, we "reset" the currently running ripple animation, but
it is hard to notice unless looking for it.
https://bugzilla.gnome.org/show_bug.cgi?id=656125
Extension developers may be confused about why their extensions aren't working:
the LookingGlass isn't a very obvious place, or even which errors are theirs.
To remedy this, save all errors per-UUID which allows them to be retrieved
later.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
Add ShellVersion, designed for detecting OUT_OF_DATE extensions so they can't
be installed, as well as ApiVersion, designed for backwards-compatibility with
the SweetTooth web-app, which must support all shell versions.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
GetExtensionInfo() takes a UUID and returns a JSON object with information
about that extension including their metadata, path and current state.
ListExtensions() takes no arguments and returns a JSON object mapping UUIDs
to the same information objects described above.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
As an effort to prevent a string freeze to land timestamps on 3.0, we reused
translations for the calendar. Now that the string freeze is long gone, make
some proper strings.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
The notification spec supports the concept of a 'default' action:
"The default action (usually invoked my clicking the notification)
should have a key named "default". The name can be anything, though
implementations are free not to display it."
Support this by invoking the 'default' action rather than a emitting
the 'clicked' signal when clicking notifications which specifie a
default action.
Also don't add an action button for the default action.
https://bugzilla.gnome.org/show_bug.cgi?id=655818
LayoutManager and Chrome are already somewhat intertwined and will be
becoming more so. As a first step in merging them, move the Chrome
object into layout.js (with no other code changes).
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Looking Glass is supposed to slide out from underneath the panel.
Rather than fiddling with Main.chrome.actor directly, just add the lg
actor to the chrome, and fix its stacking there.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
With the old pre-boxpointer summary notifications, it sort of made
sense that the summary notification actor was a child of the message
tray. But there's no reason for that now, and in fact, it ends up
requiring special cases in some places since hovering over the summary
notification counts as hovering over the tray. So, fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Rather than having the panel corners as independent bits of chrome and
manually syncing their positions, put them inside the panel actor, and
update the panel's allocation code to position them correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
The buttons should have a glassy transparent look. Also, they should not
be as tall, should light up on hover, and their labels should be white
in order to stand out. Making the labels solid white requires removing the
transparency set in modalDialog.js. Also, add a separate color setting
for the dialog as a whole - this avoids having a white icon.
https://bugzilla.gnome.org/show_bug.cgi?id=655428
The specs call for a 2 pixel gap between the panel and its menus,
though we need to specify this as 4 pixels, since it's relative to the
bottom of the icon/title, not the bottom of the panel (up until now,
the point of the menu arrow was actually overlapping the menu's
highlight underline).
Also, move the gap specification into the CSS, since it makes more
sense there.
https://bugzilla.gnome.org/show_bug.cgi?id=655627
Since this link in the keyboard menu points to Region and Language
Settings in System Settings, we should be consistent and use that
term instead of "Localization Settings"
Also, this removes ellipsis from "Show Keyboard Layout" since it
doesn't require further input.
https://bugzilla.gnome.org/show_bug.cgi?id=652984
The current check for fullscreen windows ignores the window's
minimization state, so that chrome which is hidden in fullscreen
will always hide if the window on top of the window stack is
fullscreen, even if it is actually minimized.
Instead, skip minimized windows when looking for fullscreen windows.
https://bugzilla.gnome.org/show_bug.cgi?id=655446
_fixMarkup() was supposed to be ensuring that the markup we passed to
clutter was correct, but it was validating the syntax incorrectly, and
wasn't checking that the markup was valid (or even well-formed). This
is bad because if you pass bad pango markup to
clutter_text_set_markup(), it will g_warn and drop the string on the
floor.
Fix by fixing up the regexps, and then calling Pango.parse_markup() on
the result, and just xml-escaping everything if parse_markup() fails.
https://bugzilla.gnome.org/show_bug.cgi?id=650298
Keeping the volume menu open after setting the desired volume isn't that
useful and forces a second click (or an Esc press) to dismiss it. Allow for
the sliders to be used with a single click-hold-move-release.
https://bugzilla.gnome.org/show_bug.cgi?id=649586
Move the HotCorner class from panel to layout, and make the panel
manage its own HotCorner.
Stick the panel's HotCorner into the Activities button actor (rather
than separately floating above it), so that hover tracking on the
button works properly without needing hacks in HotCorner.
https://bugzilla.gnome.org/show_bug.cgi?id=645759
The fact that everything in the top bar except the activities button
was a menu made various things difficult. Simplify this by making the
activities button be a menu too, but just hack it up a bit so that the
menu associated with the button never actually appears.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=645759 (Clicking on
Activities with menu up leaves a funny state) and its semi-dup 641253
(panel keynav between Activities and menus is quirky).
visibleInOverview chrome was visible even when the screensaver was
active. Although we may eventually need visibleInScreenSaver, that
should be a separate flag.
Fix this by tracking the screensaver active state, and hiding the chrome
when the screensaver is active.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
Fix the signal handling; you can't use this.connect('ActiveChanged')
to connect to a D-Bus signal after replacing the signal methods with
the lang.signals versions. Just leave it using the D-Bus signal names,
just like it uses the D-Bus method names.
Also, remove the "_" from "_screenSaverActive", to match what
AutomountManager checks for, and remove getActive(), since it's not
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
As _updateCount has been designed to be overwritable by subclasses,
move the check for _actorDestroyed into _setCount(), to fix the
problem described in commit 5f6ac33d5 in derived types as well.
If the resident source is destroyed, it should be recreated
immediately, so that it is available when another volume is
mounted. However, we only connect to the 'destroy' signal
on the original source, not on newly created ones. As a result,
the resident source only works twice, after that it shows up
without icon and an empty notification.
Fix by always connecting to the source's 'destroy' signal.
When trying to update the message count after a summary icon has
been destroyed, the label to display the count is no longer valid
and trying to set its text results in some Clutter warnings.
Basically do what NautilusPlacesSidebar does with the drive/volume/mount
eject/unmount/stop priorities.
We follow this pattern:
- always prefer Safely Remove if available (i.e. drive.stop())
- fallback to ejecting the mount/volume/drive if that's not possible
- finally, fallback to unmounting the mount if even eject is not
available
This also means we don't care about the distinction between
Stop/Eject/Unmount at this level. Disk Utility (or Nautilus) are
available for those who want that degree of control, but the common case
here should do the most useful action without presenting the choice.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Ideally, this would be an entirely-JS implementation, but we have a
couple of issues with gjs and gobject-introspection to work around, so
we need a ShellMountOperation class for the time being.
This first commit implements the show-processes dialog, with a system
modal style very similar to the EndSession dialog.
Implementations of ask-question and ask-password will follow shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
If possible, use the results from the sniffer process in order to have
less-generic alternatives to the file manager in the proposed autorun
choices.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Autorun preferences can be fine-tweaked at the content-type level from
the System Settings 'Removable Media' panel.
Use those settings to figure out the default action for newly-mounted
mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
The AutomountManager class is the low-level counterpart of the
previously introduced AutorunManager, and takes care of extracting the
list of valid mounts from a GVolume or a GDrive and mounting them,
provided a number of conditions and requirements are met.
AutomountManager also keeps track of the current session availability
(using the ConsoleKit and gnome-screensaver DBus interfaces) and
inhibits mounting if the current session is locked, or another session
is in use instead.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
AutorunManager is a class that takes care of displaying and managing
notifications and UI for storage devices.
When a mount appears and a number of conditions are satisified, a
transient notification will be displayed to immediately interact with
the device. AutorunTransientDispatcher is the object that takes care of
showing/hiding the notification sources as devices appear/disappear.
Likewise, current mounts are kept in a list and presented within a
list in a resident notification, handled by AutorunResidentSource.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
On error, we tried to kill and respawn gnome-power-manager, but
as of commit c5676900 the DBus interface provided by g-s-d's power
plugin is used, so the respawning does not have any effect.
https://bugzilla.gnome.org/show_bug.cgi?id=654300
When one of the networks in the main menu is removed and we have
a More... submenu, we can take the first out from the submenu and
show it in the main menu.
https://bugzilla.gnome.org/show_bug.cgi?id=647175
This is needed if we are handling an incoming text channel and then user tries
to open a chat with the same contact using Empathy. In this case, the Shell
should delegate the channel back to Empathy and just continue observing it as
it does for usual outgoing channels.
Depends on telepathy-glib 0.15.3 as
tp_base_client_set_delegated_channels_callback() has been added in this
version.
https://bugzilla.gnome.org/show_bug.cgi?id=654237
Due to an accidental addition line in commit c8670819, all switches in popup
menus accidentally gave the appearance that they were turned off.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
https://bugzilla.gnome.org/show_bug.cgi?id=654267
We don't want sources that are no longer associated with a running application
to stick around in the message tray.
Message tray sources were removed when the associated application’s state
changed to Shell.AppState.STOPPED . This caused sources for applications
that were still running, but did not have any open windows to be removed.
Instead, we should use the notification’s sender removal from DBus as an
indicator for when to remove the associated source from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=645764
If we're typing we want to send composing. If we empty the entry we
want to send active. If we're typing but don't type any more for
COMPOSING_STOP_TIMEOUT seconds, we want to send paused. Simple.
This behaviour was stolen from Empathy where it has won many awards.
https://bugzilla.gnome.org/show_bug.cgi?id=650196
Based on patch from Jonny Lamb <jonnylamb@gnome.org>
Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
Commit 64b2b4a7d4 changed the monitor layout handling, resulting
in some layout errors due to a subtle change in memory handling:
when zooming a window in the overview, the available zoom area is
calculated by subtracting the panel height from the primary monitor
area. This area used to be a copy of the monitor rect, but as now
the rect itself is returned, zooming a window on the primary monitor
repeatedly modifies the monitor rect, leading to layout errors in
various parts of the shell.
Fix by using a copy when calculating the available zoom area.
https://bugzilla.gnome.org/show_bug.cgi?id=654105
Use a longer fade-in time, but with an inout transition, so that the
dialog starts fading in very slowly and then picks up speed after
150ms or so. That way if the user releases Alt+Tab right away, they'll
never actually see the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=652346
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
Every place that called chrome.addActor was specifying
visibleInOverview:true, and no existing designs call for chrome that
disappears when you enter the overview, so just drop that as an
option.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
Due to lockdown settings or Polkit policy, shutdown may not be
available. If this is the case, the "Power off ..." action should
be hidden from the user status menu.
https://bugzilla.gnome.org/show_bug.cgi?id=652038
Sliding out the workspaces pager when starting a drag causes a lot
of motion. With the pager only hiding if workspaces are not used,
it is better to require to explicitly hover the workspaces sidebar
for the sliding.
https://bugzilla.gnome.org/show_bug.cgi?id=652730
Use the new PopupSwitchMenuItem functionality when bluetooth cannot
be enabled. Use it also for showing "connecting..." when activating
device items.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
Moves and converts NMDeviceTitleMenuItem from network.js into
PopupSwitchMenuItem, so that it can show both a switch and a
greyed-out status label. This will be soon used by the Bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
_createNetworkItem was always appending access point at the end of
the menu when their position was < 5 (NUM_VISIBLE_NETWORKS), ignoring
the presence or absence of _overflowItem, which thus ended in the
middle of the network list. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=652313
After completing the overview transition, the workspace view is
clipped to avoid overlapping the search entry/view selector titles
while switching workspaces. For clipping, the view's position and
size was used, which works well assuming that the workspace pager
will start hidden or stay zoomed out while the overview is visible.
However, that assumption holds no longer true, as auto-hiding the
pager now depends on the number of workspaces, and thus may change
while in the overview. For instance, when starting with the pager
being visible, the clip area ends up being too small when moving
all windows to the first workspace (and thus triggering auto-hide).
As a fix, handle the clip rectangle separately from the view's
geometry, and set it always to the area the workspaces would
occupy with the pager hidden.
https://bugzilla.gnome.org/show_bug.cgi?id=653142
We call global.sync_pointer() on MetaScreen::restack as a hack to try
to fix up the hover state after a pointer grab. Previously we were
doing this in chrome.js, since there was already a ::restack handler
there anyway, but this isn't really related to the chrome at all, so
move it to main.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
This is better for memory management, and we'll see any errors this
way, which we may eventually want to do something with.
We need to make this change because gjs recently started checking
(allow-none) on callbacks.
Workspace thumbnails are supposed to be miniatures of the "real"
workspace they represent, but currently they show minimized windows
like the window picker.
Instead, hide minimized windows and track changes to update the
thumbnail accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=651569
With commit 59a3e393f9 whether the workspace pager should autohide
now depends on the number of workspaces. As we only track changes
to the number of workspaces while the overview is visible, we miss
changes in "normal mode", i.e. when creating a new workspace by
moving a window with ctrl-alt-shift-arrow; as a result, the pager's
autohiding might be incorrect when entering the overview after that.
As a fix, keep tracking changes to the workspaces when the overview
is hidden and update the zoom options.
https://bugzilla.gnome.org/show_bug.cgi?id=653078
Commit 429f809b7 fixed an exception in getDragActorSource(), but
the returned actor is only an approximation (e.g. in contrast to
the actual drag actor, it includes the label).
Try a bit harder to return the correct actor and only fall back to
the approximation when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=645990
The purpose of autohiding the workspace pager on the right was to
avoid exposure of workspaces to users who are not using them.
However, for users who do use workspaces, the behavior limits the
purpose of the overview. To fix, always show the pager if more than
one workspace is actively used.
https://bugzilla.gnome.org/show_bug.cgi?id=652714
Using the list of stylesheets loaded with st_theme_load_stylesheet(),
one can build an StTheme that is completely identical to the previous
one, except for one property (application-stylesheet).
This allows rt and the user-theme extension to work while respecting
the theming of other extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=650971
Currently the user has to find an empty spot in the workspace
to be able to launcha new instance of an app using dnd.
This is unnecessary hard, so just allow dropping on windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=652079
The screen panel in System Settings has a preference whether the
screen should be locked on suspend. This works fine when suspending
by closing the lid, but the "Suspend" menu item in the user status
menu ignores the setting and always locks the screen.
Fix by activating the screen saver before suspending rather than
locking explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=652327
As the Shell does more than observing channels (users can interact with them),
it has to be an Handler as well. We have to make sure that all the new
incoming text channels are handled by the Shell by default, so we make it an
Approver as well.
From an user point of view, the only difference is that Empathy's tray icon
will stop blicking when receiving new channels.
We rely on ChannelDispatcher.DelegateChannels() and PresentChannel() to
interact with Empathy. Those methods have been implemented in
telepathy-mission-control 5.9.0 and telepathy-glib 0.15.0.
If we have more than 5 (which can happen with VPN connections), place
them into a More... submenu, which also becomes scrollable if needed.
To protect from race conditions and ordering issues while reading
connections, sort them in alphabetic order when the timestamp is equal.
https://bugzilla.gnome.org/show_bug.cgi?id=651602
shell_global_get_memory_info() is a new function which extracts a few
global counters we have already, namely glibc's mallinfo, spidermonkey's
JSGC_BYTES, and gjs' counters for boxed/object/etc wrappers.
There is some slight overlap with perf; ultimately though I'd
like this function to do some more extensive analysis, so it wouldn't
be quite the same.
perf is going to be mainly concerned with how big the whole process
over time is; memory_info is for debugging memory leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=650692
When timestamps or presence or alias changes were appended before,
the _history could grow unbounded, leaving behind an unfruitful chat
log of:
Jasper has gone offline.
Jasper has gone online.
Jasper has gone offline.
Jasper has gone online.
ad nausem.
https://bugzilla.gnome.org/show_bug.cgi?id=651086
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
Currently the workspace geometry is updated on zoom/allocation
changes, which means that newly added workspaces use their initial
geometry of (0, 0, 0, 0) until the next zoom change. As a result,
windows on the affected workspaces are mispositioned, e.g. placed
outside the workspace area. To fix, set the geometry on newly added
workspaces to the view's cached values.
https://bugzilla.gnome.org/show_bug.cgi?id=649001
Workspaces used to contain the desktop background, so when a
workspace was removed, we animated its actor to an off-screen
position before destroying it. As the background has been
removed a while ago, we can destroy the actor directly.
https://bugzilla.gnome.org/show_bug.cgi?id=645031
If the former is empty (default), only the extensions not contained in
the latter are loaded. Else, all extensions in the former that are
not contained in the latter are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=651088
We should only show the trash can when the user starts dragging a
favorite from the dash, not when the user starts dragging an application
that happens to be a favorite via a window or an application icon
in the applications view.
https://bugzilla.gnome.org/show_bug.cgi?id=642895
Some users are confused when their devices are not shown in the
network menu, even if they configured them manually. Mark their presence
by showing them in the menu, even if they cannot be otherwise
interacted with.
Also add a status string for deactivating devices (none currently,
soon will appear in NetworkManager).
https://bugzilla.gnome.org/show_bug.cgi?id=646946
A new envrionment variable GNOME_SHELL_ENABLE_CLEANUP is added which
causes us to attempt freeing global data. The reason this isn't
enabled by default is that it's a waste of time at best, and at
worst in corner cases could cause crashes which would fill up
crash databases. Better to leave it as a developer-only tool.
Start stubbing out some cleanup in ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=649517
Since both the hot corner's ClutterGroup and the hot corner's
ClutterRectangle button-release-event is connected to
_onCornerClicked() we must handle it there by returning 'true' to
Clutter or else _onCornerClicked() is called twice which defeats the
HOT_CORNER_ACTIVATION_TIMEOUT logic.
https://bugzilla.gnome.org/show_bug.cgi?id=649427
If you receive a message, a notification will appear. If you reply in
Empathy's chat window before the notification disappears, the
notification is updated with the contents of the message you *just*
sent! We should only update notifications if they're incoming.
https://bugzilla.gnome.org/show_bug.cgi?id=650219
Signed-off-by: Jonny Lamb <jonnylamb@gnome.org>
AltTabPopup was calling global.stage.get_actor_at_pos() "to force a
stage relayout", but that function does not actually have that effect.
It was also occasionally causing Clutter warnings (possibly due to a
clutter pick-buffer-caching bug?). So just remove the call.
https://bugzilla.gnome.org/show_bug.cgi?id=650317
Move some more environment-initializationy stuff from main.js to
environment.js, and be more careful about not importing shell JS
modules until after the environment has been fully patched.
Change gnome-shell-plugin to call Environment.init() before
Main.start(); this means that Environment.init() now runs before any
shell JS modules (besides environment itself) have been imported.
Make run-js-test create a ShellGlobal and use its js_context, so that
the shell_global_set_property_mutable() stuff in Environment.init()
will work correctly in tests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=649203
The lg window was losing focus when the page with the entry got unmapped;
fix it to refocus itself after that.
Fixing this problem revealed that previously we were focusing the
entry on open(), but not ensuring that that page was selected, meaning
you could type into the entry without being able to see it. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=647303
The mouse-wheel zooming "easter egg" breaks horribly when you
drag a window, due to ugly lightbox reparenting tricks it uses.
For now, just end any zoom before we drag the window around.
https://bugzilla.gnome.org/show_bug.cgi?id=649632
All WPA APs were getting set as WPA2 due to the check for privacy;
WPA/WPA2 APs *must* set the Privacy bit according to the standard,
so we'd never end up in the case for NMAccessPointSecurity.WPA.
Fix that, and also add flags for WPA[2] Enterprise which we'll
use a bit later for the first-time connect case for 802.1x enabled
access points.
Instead of rolling our own code, use new libnm-glib functions to do
the same thing. Requires libnm-glib as of
779215c742bbe29a2c66202ec7e2e6d43edeb8ff (which will be part of 0.9).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=648648
A "cosmetic" code arrangement I requested in code review resulted
in one too few items being removed from the queue for each incremental
chunk of icons added. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=648739
We used used to indicate to the user the ability to move to another workspace
during dnd by highligthing the adjacent workspaces on hover.
This was done by changing the workspace's opacity to 200 and set it to
255 for the highlighted adjacent ones.
This is now no longer needed as the design was completely changed since
then (overview relayout; we no longer represent workspaces in the way
we did before) and introduces a bug where we don't properly reset the
opacity after the drag action, so just remove that code.
https://bugzilla.gnome.org/show_bug.cgi?id=648983
If a user is fast and mouses over a window while the workspace thumbnail
animations are playing, it can be frustrating when the close button won't
appear at the end of the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=645848
The initial selection of the Alt+Tab dialog was happening before the
dialog was shown and allocated, and so the "do we need to scroll"
check used bogus coordinates. Fix by showing the dialog (and forcing
an allocation) first.
https://bugzilla.gnome.org/show_bug.cgi?id=647807
Previously, we skipped rebuilding device items in case the device
had already been seen, but this caused the connected switch not to
be updated. Now it has been refactored to update in case the device
changes, and to create only when the device is completely new.
https://bugzilla.gnome.org/show_bug.cgi?id=647565
Connect to button-press-event on the menu item actor, not on the
slider, so any part that is highlighted is also clicked. This means
that click on the left of the volume slider is a rapid way to mute.
https://bugzilla.gnome.org/show_bug.cgi?id=646660
Adds a function that compares wireless networks and keeps them sorted
at all times. Order is: first already configured connections, then
first secure networks, then alphabtic. Also, the appearance of a new access
point no longer causes the whole menu to be rebuilt (but it still linear
searches for the position, I guess that could be skipped), which caused
the addition of more code for tracking the active access point.
https://bugzilla.gnome.org/show_bug.cgi?id=646580
Rename a few Panel fields and add a _statusArea object pointing to the
status area PanelButton objects. You can now address each item
consistently from lg:
Main.panel._activities
Main.panel._appMenu
Main.panel._dateMenu
Main.panel._statusArea.a11y
Main.panel._statusArea.volume ...
Main.panel._userMenu
https://bugzilla.gnome.org/show_bug.cgi?id=646915
If a JS object has an 'actor' property pointing to a ClutterActor,
include the actor's toString() output in the delegate's toString()
output. Eg:
js>>> Main.panel
[object Object delegate for 0xff6080 StBoxLayout.menu-bar "panel" ("Activities")]
https://bugzilla.gnome.org/show_bug.cgi?id=646919
To keep the app icon from overlapping the panel's (border-image)
border, a custom property for clipping the app menu icon's bottom
was introduced. But if the clip region is set before the initial
icon is set, the entire actor ends up clipped. Also due to the double
meaning of clutter_actor_get_height() (e.g. preferred height versus
allocated height), the clip region may end up too large and the icon
overlaps the panel's border-image.
Fix both problems by updating the clip region on size changes as
well, rather than on style changes only.
https://bugzilla.gnome.org/show_bug.cgi?id=644122
The IP_CHECK and SECONDARIES states should be considered part of the
"connecting..." phase.
DEACTIVATING should be its own stage, but that would break string
freeze, so we just treat it like DISCONNECTED for now.
UNMANAGED needs to be treated differently in 3.2, but it is too late
to fix it for 3.0.1.
https://bugzilla.gnome.org/show_bug.cgi?id=646946
Alt+Tab's special case of "switch to the most-recently-used window even if
it's in the same app" is actually an hindrance for users to get a firm mental
model of Alt+Tab. Now that we have Alt+Above_Tab the special case is no longer
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=647907
Currently, the banner text is always located at the right of the
title - we need to swap those around for RTL locales. Rather than
using the locale directly to figure out the ordering, try to
determine the direction of the title label and let it control the
overall direction of the notification - this way, notifications
generally come out right when mixing scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=646921
In the current implementation of the search entry, when replacing a
selected search term with another term, the first character of the
replacement is prepended to the hint text rather than starting a new
search. This fix makes sure that the focus is not lost when changing
the selected search term.
https://bugzilla.gnome.org/show_bug.cgi?id=636341
When updating search results, the current result set is
recreated from scratch before setting the selection
highlight. This results in two style changes of the selected
item, and as a CSS transition is used to animate the style
change, the selected item flickers if it remains the same as
with the previous search term.
Fix by hiding the result set until the selection is set, to
avoid the transition in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=646019
The addition of _backgroundStack to ModalDialog broke focus
navigation, because it was interposed between the focus group root and
all of the interesting content, but since it isn't an StWidget,
st_widget_navigate_focus() was unable to navigate through it. Fix this
by moving the focus root to this._dialogLayout (inside the
_backgroundStack) instead.
Additionally, in EndSessionDialog specifically, _initialKeyFocus
wasn't being set until after opening the dialog, so it was ignored.
Also change ModalDialog.close() to clear the _savedKeyFocus that
popModal() set, so that dialogs that are repeatedly closed and
reopened will have their focus revert back to _initialKeyFocus each
time.
https://bugzilla.gnome.org/show_bug.cgi?id=646740
The icon set as secondary icon of the search entry depends on whether
a search is active or not - clicking the icon should reset the entry
only in the former case. This is implemented by connecting/disconnecting
the 'secondary-icon-clicked' signal when updating the icon, but an
additional signal connection was left-over when refactoring the search
entry, resulting in clicks on the inactive icon removing the hint text.
Fix by removing the stray signal connection.
https://bugzilla.gnome.org/show_bug.cgi?id=646855
The change to StTextureCache for bug 644142 broke lg's inspector icon,
which was not specifying St.IconType.FULLCOLOR, but was relying on the
fact that SYMBOLIC (the default) would fall back to it. Fix the icon
by specifying FULLCOLOR explicitly.
(We should probably be using a symbolic icon here, but there is no
available icon with a select/pick/point-to/etc kind of meaning.)
https://bugzilla.gnome.org/show_bug.cgi?id=646451
When more than one device exists, we need to reset the section title's
device to null, and in that case we must show nothing (neither the switch
nor the label, but an empty label is OK anyway). Also, we need to
update the device statusItem immediately when constructing it, as we
may not get any state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=646074
NMDeviceModem._createSection was not checking whether it should have
shown the connection list, resulting in status item shown even if
the device was in an invalid state.
Also, fix a logic error when creating the operatorItem and fix overriding
_clearSection protected method.
https://bugzilla.gnome.org/show_bug.cgi?id=646395
NMApplet connects to each NMDevice's state-changed signal and stores
the signal handler id on the NMDevice itself. However, it was using
the same name as NMDevice itself was using to store the handler ID for
the underlying GObject's state-changed signal, thus overwriting it,
and resulting in *neither* signal handler getting removed if the
device went away. (This probably isn't a problem, since the device is
going away, but it causes a warning.)
Also, at least for WWAN devices, the device state changes to UNMANAGED
immediately before disappearing, but getStatusLabel() wasn't handling
that case and printed a warning instead. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=646708
If you restart NetworkManager, then the list of active connections
is emptied, then comes back with the same GObjects in it. If the
_primaryDevice field isn't cleared on the object, then we won't
know we need to set it back on the device, resulting in the active
device not showing up in the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=646558
A notify signal does not include the new value of the property in
its signature, so the handler was trying to compare a GParamSpec with
a number when updating. Fix it to always retrieve the value from the
object.
https://bugzilla.gnome.org/show_bug.cgi?id=646443
ViewByCategories._removeAll clears the sections, but the filter passed
to view still expects them to exists. Therefore, refresh the view
after the section has been rebuilt and the All filter reapplied.
https://bugzilla.gnome.org/show_bug.cgi?id=645801
Right now, the network menu will overflow the screen if More...
is selected with many access points. As a short-term workaround
for this, add a scrollbar for submenus of panel dropdown menus
if they would cause the toplevel menu to overflow the screen.
- Put the actors in a PopupSubMenu in a StScrollView so we get
a scrollbar if the allocated space is smaller than the height
of the menu. Expand animation is turned off in the scrolled case
to avoid weirdness.
- When we pop up a panel menu, set a max-height style property
on the panel menu to limit it to the height of the screen.
- Hack event handling while the scrollbar is dragged to make
the scrollbar work properly.
https://bugzilla.gnome.org/show_bug.cgi?id=646001
Since the icon area is end-aligned, the signal strength icon for
insecure networks was ending up aligned with the lock icon for secure
networks. Fix that by always including a _secureIcon, but having it be
blank for the insecure networks.
https://bugzilla.gnome.org/show_bug.cgi?id=646121
Adding correct annotations to Gio.File.load_contents revealed that gjs
doesn't actually support array+length combinations. For 3.0 this would
be invasive to fix, so add a method to ShellGlobal which does what
we need.
https://bugzilla.gnome.org/show_bug.cgi?id=646333
Figuring out the size of an unmapped actor is not completely
reliable because styles aren't fully assigned until an actor
is mapped. So show the submenu before computing the size we
want to tween to.
https://bugzilla.gnome.org/show_bug.cgi?id=645949
Some connection types (like wimax) are not supported by the menu, and
should be ignored instead of throwing exceptions. Also, NetworkManager
had a bug that sent connections with invalid settings. This should not
happen, but in case it does, we will not blow up, but just log a warning
and continue silently.
https://bugzilla.gnome.org/show_bug.cgi?id=646355
When a device is connecting, we can continue showing available
connections and access points, as well as the active one with the dot.
(Hiding was a remnant of when the device status was on a different
menu item than the title)
https://bugzilla.gnome.org/show_bug.cgi?id=646381
A cosmetic change recommended in review of the patch to fix the
VPN Connections switch ended up introducing a logic error that
made the switch not work properly. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=646380
It was always reporting true, even if disconnected. At the same time,
add a signal that is emitted when state changes and update the UI
accordingly.
In the future (with another libnm-glib API break) we should use the
NMVPNConnection object to track the connection state, so that we can
show if we're connecting or we need authentication.
https://bugzilla.gnome.org/show_bug.cgi?id=646380
NMDevice._findConnection expects an uuid as parameter, but
checkConnection was passing a NMConnection object. This caused
exists to be always false, thus the connection was added again every
time the 'updated' signal was emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=645702
When a source has an associated tray icon, we would forward all clicks
to the X11 window, meaning that the summary notification could not
be opened. Instead, restore normal event flow for clicks, when the
source has notifications in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=645753
Since the opacity of the application menu is controlled by
it's _targetIsCurrent flag, we need to respect that when entering
and leaving the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=645734
Sometimes, log messages are hard to differentiate from normal,
unread recent messages, so give a separate style to messages
retrieved from the TelepathyLogger service.
https://bugzilla.gnome.org/show_bug.cgi?id=645609
If we have a date that's not within the last week, it's really
confusing to display it as "Sent at 9:23 on Tuesday". Steal
some strings from calendar.js for displaying older dates to
avoid a string-freeze break.
https://bugzilla.gnome.org/show_bug.cgi?id=645609
This ensures that we don't show a small black blob fading away
when the user clicks on the notification and it is removed.
Set HIDING state right away in _hideSummaryBoxPointer() so that
it is only called once. Update this._pointerInTray when the tray
is unlocked, so that we are not dependent on escapeTray() being
triggered by 'done-displaying-content' signal.
https://bugzilla.gnome.org/show_bug.cgi?id=645697
Use Meta.later_add() with BEFORE_REDRAW rather than Mainloop.idle_add()
to add the banner body so that the notification body is reliably added
after the first frame is drawn. This is important for notifications that
are expanded right away, such as the summary notifications that
were not shown as banners because the user was in the Busy mode or was
interacting with the summary. Otherwise, these notifications were sometimes
shown with an ellipsized banner and were only getting full content when
they were done animating.
Only add expanded content and signal the change once. Previously, we
used to signal the change numerous times and processing this signal was
holding up processing other things, such as the user moving the mouse
away from the notification so that the notification collapses.
https://bugzilla.gnome.org/show_bug.cgi?id=645719
Since the hotcorner is a reactive actor, and it is over the Activities
button, hovering on it results in a leave-event for the button.
This is not noticeable when opening the overview, as the button is
correctly prelighted, but it is when closing, if you keep the mouse
near the hot corner, as the button is kept in normal state, despite
the mouse being over it.
https://bugzilla.gnome.org/show_bug.cgi?id=645751
Instead of setting the x/y position of the box pointer, which results
in a long change of workarounds for limitations of the Clutter
layout system, set the anchor point instead, which takes the
positioning out of the layout system.
The position is computed as a combination of the position computed
from the allocation and the box pointer's size, and an offset that
we tween when animating showing and hiding the box pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=645744
Using ClutterActor.get_transformed_size() can produce bugs if we
happen to position the box pointer when the source actor has a
relayout queued. Use our newly added reliable utility function
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645744
Commit 31b12635d1 fixed links in notifications again, but blocked
clicks on normal labels getting through to the notification. Fix
this, so that both links and dismissing notifications work again.
https://bugzilla.gnome.org/show_bug.cgi?id=645839
Add a translator comment for the "Sorry, that didn't work. Please try
again." string, as suggested by several people; this should help
translators what "that" refers to.
As a stop-gap measure until we have a native input method tray icon,
add ibus-ui-gtk to STANDARD_TRAY_ICON_IMPLEMENTATIONS so that the IBus
status icon shows up in the status area rather than in the message
tray. The message tray location doesn't work for the function of
showing the current input method when switching between windows or
changing input methods.
https://bugzilla.gnome.org/show_bug.cgi?id=641531
StThemeNode.get_length() doesn't necessarily return an integer pixel
value, and our code produces non-integer positions in that case. So
round the spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
Because of the GtkSizeGroup-like trickiness we're doing with
PopupMenuItems, we need to force Clutter to discard its cached size
requests for them any time the menu itself changes size.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
If the BoxPointer changes size (eg, when opening the "More" section of
the network menu), reposition it to make sure it's still aligned
correctly and still completely on-screen.
This is not the right fix for this problem (and causes the menu to be
drawn in the wrong position for one frame). The right fix would
involve a ClutterConstraint, but that would be more invasive, and can
happen post-3.0.0.
https://bugzilla.gnome.org/show_bug.cgi?id=645647
The change to make Notification an StButton (06d2c0af, bug 642978)
broke links, because the link actor would ignore the
button-press-event, allowing the notification actor to receive it and
get a pointer grab, and so the link actor would never see the
button-release-event. Fix that by accepting and discarding the
button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=645613
The chat-history-fill-in code had logic to avoid appending two
messages when a message appeared in both the log and the pending
messages. But it wasn't working because of an incorrect object field
name.
Additionally, the code was previously keeping the copy of the message
from the log, and suppressing the copy from pending. But that meant
that once the previous bug was fixed, it would think it had only shown
old messages, and so it would create a source but not notify it. So
fix it to suppress the log message and show the pending message.
https://bugzilla.gnome.org/show_bug.cgi?id=645612
For wired devices (actually, ethernet devices), hide the connection
list when there is only one connection (either automatic or stored).
The device can be operated with the associated switch.
Since device state Unavailable is generic and has substates, instead
of using an hack for carrier, introduce some code that checks both
for carrier and firmware-missing when in that device state, and updates
the UI accordingly.
If a notification was updated while one of its widgets was focused,
it would lose the grab when that widget was destroyed. Fix that by
moving the focus to a safe place before destroying the old widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643687
We want to minimize focus stealing from the user. If a non-urgent notification
comes in while the user is interacting with the tray, we add it to the tray
and only show it after the user is done interacting with the tray. If an
urgent notification comes in while the user is interacting with the tray,
we hide the tray and show the urgent notification.
https://bugzilla.gnome.org/show_bug.cgi?id=636838
We want to allow the user to scroll through all notifications from
source by using a single scrollbar. We suppress the individual
scrollbars inside the notifications.
As one exception, we keep the original scrollbar for chat notifications
because it has a distinct look, ending above the text entry box.
https://bugzilla.gnome.org/show_bug.cgi?id=611611
Change the way menu items allocate their contents to take text
direction into account, so they're fully reversed in RTL locales,
and St.Align.START / END are respected.
https://bugzilla.gnome.org/show_bug.cgi?id=645524
While we have menu for an app icon open, we want to show the prelight
for the item instead of removing the prelight when the user mouses
away from the item and into the menu, and if there's a tooltip
(like for the dash), we want to show the tooltip immediately when
the menu is popped up.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
It can be useful to avoid sending enter/leave events to the source actor
of a menu: this would be the case when the source actor isn't a menu item
that should participate in menu navigation but rather is some object
(like an app icon) that we want to indicate corresponds to the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
Inside the Shell, all the UI (including chrome, the overview, and
the actual windows) is not a child of the stage but of a special
ClutterGroup, which is cloned inside the magnifier.
Add function for setting this special actor so that actors added by
St are visible in the magnifier. Nothing yet uses this, but the
tooltip will soon.
https://bugzilla.gnome.org/show_bug.cgi?id=635100
We need to update WorkspacesView._ZoomOut before calling
_updateWorkspacesGeometry() in show(), as otherwise the old
value is kept. This was a problem if we previously left the
overview zoomed out.
The applications have to have a way of keeping resident notifications
updated without unnecessarily notifying the user with the information
the user is already seeing in the application window.
https://bugzilla.gnome.org/show_bug.cgi?id=630847
Make summary sources look more clickable and highlight them when selected.
Highlighting the fully expanded summary source when selected matches the
highlighting in the top bar items and teaches the user that any part of the
expanded summary source can be clicked.
Based on the initial patches by Florian Müllner and Jonathan Strander.
https://bugzilla.gnome.org/show_bug.cgi?id=644788
The lightbox will be sized to the size of its parent container,
so we need to make the parent container reliably the size of the
stage, instead of letting it be auto-sized to the size of its contents.
https://bugzilla.gnome.org/show_bug.cgi?id=644889
Returning true from the event handler seems to avoid getting
duplicate return events; these duplicate events likely are
getting generated by IBus.
https://bugzilla.gnome.org/show_bug.cgi?id=644509
Currently activating a window on a different workspace requires very
long drag distances, which is very inconvenient to use.
Fix that by allowing switching workspaces using the thumbnails which is
consistent with window and launcher dnd and much easier to use.
https://bugzilla.gnome.org/show_bug.cgi?id=643945
Don't do an individual hover fixup for every window overlay, instead
just use the new global.sync_hover() to fix up hovers once we have
finished showing the overview.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=638613
Main._nWorkspacesChanged was racing with Main._checkWorkspaces.
If _checkWorkspaces won the race, _workspaces was uninitialized.
Because of this, _checkWorkspaces only noticed workspaces
with windows on them, leading it to believe the last workspace wasn't
empty, and added a new, empty workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=645343
In the case where the original actor is destroyed, we don't
show a snap back animation, so we need to destroy drag actor
as we would do in _onAnimationComplete.
https://bugzilla.gnome.org/show_bug.cgi?id=640781
If you have XFixes 5 (and corresponding xserver support) then we
add barriers on the panel and in the message tray corner so that
its easy to reach the corners even when there are monitors to the
sides of the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=622655
If the user clicks a trayicon in the overview, drop out of the
overview before passing the click on to the icon. (We have to actually
wait for the overview animation to complete, in case the icon wants to
get a pointer grab, which it would not be able to do with the overview
active.)
https://bugzilla.gnome.org/show_bug.cgi?id=641853
If the pointer moves on or off the stage while another process has a
grab, we will lose track of it. One example of this is that if you use
a popup menu from a message tray trayicon, the tray will stay up after
the menu goes away, because the shell never saw the pointer leave it.
Add a new method shell_global_sync_pointer() that causes clutter to
recheck what actor is under the pointer and generate leave/enter
events if appropriate.
Of course, we can't actually tell for sure when another process has a
grab, so we need a heuristic of when to call this. Currently we call
it from Chrome._windowsRestacked(), which is not really the right
thing at all, but does fix the menu-from-trayicon case...
https://bugzilla.gnome.org/show_bug.cgi?id=630842
If the user clicks on the title of a trayicon's SummaryItem, forward
that click to the trayicon. Also adjust
gnome_shell_plugin_xevent_filter() so that if the trayicon takes a
grab as a result of this, we don't hide the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=630842
If you run a command from Alt+F2 that tries to get a server grab (eg,
xmag), it will fail if it starts up before the run dialog is finished
hiding.
Additionally, the run dialog currently stays focused while it is
fading out, potentially stealing keystrokes (or causing the user to
accidentally launch two copies of a program).
Change ModalDialog.close() to call popModal() immediately
Add a ModalDialog.popModal method, and call that before running the
RunDialog command. If the command succeeds, close the dialog as
before. If it fails, call ModalDialog.pushModal() to put things back
to normal before displaying the error.
https://bugzilla.gnome.org/show_bug.cgi?id=644857
When right-clicking on an AppWellIcon, the icon will become focused,
which (presumably via style-changed) invalidates its current
allocation, causing "icon.y" to return 0 until it has been
reallocated, messing up our idea of where in the AppDisplay the icon
is. Work around this by calling get_allocation_box() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645162
If there is a monitor to the right it is very easy to overshot the
expanding thumbnails and enter the next monitor. So, in that case
we just always show it.
https://bugzilla.gnome.org/show_bug.cgi?id=641877
Specify x-fill and y-fill true for the bin that contains the status
icon so the status icon will always be sized to our specified icon
size (24x24). This prevents pathological behavior for legacy status
icons embedded in the tray where an initial allocation at 1x1 before
they had content would "stick", and the icon would permanently
end up 1x1.
https://bugzilla.gnome.org/show_bug.cgi?id=634820
Right now, the user status menu always contains actions to logout
and lock the screen, and the user switching action only depends on
the technical availability of the functionality.
All those items should honor the lockdown settings defined in
org.gnome.desktop.lockdown.
https://bugzilla.gnome.org/show_bug.cgi?id=645335
To avoid having hot corners that accidentally trigger when e.g. trying
to hit the panel on the primary monitor we add hot corners only to
monitors that are "naturally" top left (top right for RTL).
For instance, we'd like a hot corner here:
corner -> +-------------
| |
+---------+ |
|=========| |
| | |
| | |
| | |
+---------+------------+
But not here:
unexpected hot corner
↓
+---------+-------+
|=========| |
| | |
| +-------+
+---------+
https://bugzilla.gnome.org/show_bug.cgi?id=645116
The fade effect when switching tabs should only be applied when
switching from a previously selected tab, not when selecting the
initial one - otherwise, the window previews are faded in the first
time the overview is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=644389
When we were knocking off workspace height to fix the ratio problems, we
weren't adding spacing in between workspaces, so they smooshed up against
each other whenever we took height off, causing them to be visible.
Different methos are being used to launch the control-center panels of each
status icon. Standarize on Shell.AppSystem.
This also fixes the network icon using a non-existant Util.spawnDesktop()
method.
Bug #645091
Commit fcfd17e was overzealous when simplifying the previous spinner
animation, as a result the spinner now stays around when switching
to another application while the animation is ongoing.
If a workspace becomes empty due to a window changing to/from the
primary monitor, but not changing its original workspace then we
were not noticing this. This can happen for instance if you drag
a thumbnail window to a non-primary window.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Notification was connecting to button-release-event to decide when to
be dismissed, which caused problems with widgets inside the
notification that reacted to button-press-event but not
button-release-event. Fix this by wrapping the Notification's table in
an StButton and connecting to 'click'.
https://bugzilla.gnome.org/show_bug.cgi?id=642978
In commit 9bd22dc0, I introduced an API to load an arbitrary
.desktop file, not necessarily from the menu path. It turns
out this function was broken because it created ShellApp instances
that were *different* from ones that were cached normally.
As far as I can tell, we didn't initially use it. Then later
Util.spawnDesktop was created which used this function.
Remove this broken function and all callers; if we're loading
.desktop files from *outside* the menu path, we can look at
readding.
This patch also kills off Util.spawnDesktop in favor of callers
talking to ShellAppSystem directly, now that the latter reports
errors.
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Move the "system notification error" handling out of
util.js, and add it to ShellGlobal so we can start
calling it from across the codebase better (including
C).
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Simplify the accounting of which windows we should dim by checking
the current state of windows rather than trying to track changes,
and by keeping a list of dimmed windows rather than a list of windows
with a dimmed parent. Remove windows from the list of dimmed windows
when they are destroyed.
This should fix problems where destroyed windows could end up in
the list of dimmed windows.
https://bugzilla.gnome.org/show_bug.cgi?id=644167
Adds an implementation of nm-applet in javascript. Uses the new
introspection from NetworkManager, and temporarily requires
nm-applet to be running for the secret service.
Features a renewed interface, with each device controllable through
a switch, which if toggled off disconnects, and if toggled on
connects to the most recently used valid connection. More esoteric
features like creation of ad-hoc networks have been moved to the
control center panel.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
Inside the inner loop, use the inner iterator, not that of the outer
loop. At the same time, refactor the code to rely less on private
properties appended to foreign objects.
https://bugzilla.gnome.org/show_bug.cgi?id=644858
The polkit authentication dialog contains logic for
falling back to dispalying a user's username if that
user has no real name.
This logic is no longer needed because gdmuser does it
internally now.
https://bugzilla.gnome.org/show_bug.cgi?id=644765
Commit 0207f1f29b landed a new
way of zooming, but was causing all sorts of window positioning
weirdness because the positions were supposed to be working against
a proportional workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=644542
Do a basic job of converting font sizes from pixels to points, so they
will scale will the global GNOME scale factor. Some other sizes that are
clearly related to the font sizes are changed to ems, but no comprehensive
attempt is made to get rid of px units.
https://bugzilla.gnome.org/show_bug.cgi?id=636868
During application startup, we used to display a rotating spinner
which also moved from left to right, revealing the application title.
The result looks rather busy, so remove the horizontal movement.
https://bugzilla.gnome.org/show_bug.cgi?id=640782
Update the Source title when an contact's alias changes, and
also also add a minor meta message like the current timestamps.
Updating the alias of a 'presenced' contact will overwrite the
current title, and it will also not update the summary item title
right now due to limitations of the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=642793
WorkspacesDisplay removes its dragMonitor in _dragEnd, but
this was never called in when a xdnd drag ended causing
dragMonitors to stack up and handling events multiple times.
Fix that by making sure that _dragEnd is called when xdnd ends.
https://bugzilla.gnome.org/show_bug.cgi?id=644642
Monkey-patch Date.prototype.toLocaleFormat() with a version that uses
g_date_time_format() since the Spidermonkey built-in can't handle
format strings with Unicode characters.
https://bugzilla.gnome.org/show_bug.cgi?id=643350
If we don't update every second, we may show the wrong time for up to
a minute on 1. resume; or 2. when changing the time; or 3. when
changing the timezone. This is both annoying and and leads to people
thinking that the tool for changing the time / timezone is broken.
https://bugzilla.gnome.org/show_bug.cgi?id=635840
Signed-off-by: David Zeuthen <davidz@redhat.com>
The mockups are here
https://live.gnome.org/GnomeShell/Design/Whiteboards/AuthorizationDialog
Detailed changes
- Don't use an icon for root
- For root, show Administrator in red
- Nuke icons for info and error messages
- Make error messages yellow
- Use 10pt size for error and message labels, not 12px
- Don't make the dialog change size when (single-line) error/info
messages appear
- Spacing fixes
- Show "Sorry, that didn't work. Please try again" if authentication fails
- Don't cancel the PolkitAgentSession if the session has already completed
https://bugzilla.gnome.org/show_bug.cgi?id=644737
Signed-off-by: David Zeuthen <davidz@redhat.com>
In the mockups the slider does not have an uniform color but uses
one color (shade of blue) to indicate the current value and one
to indicate "the rest" (shade of grey).
So adjust the slider to look like that to be closer to the look
in the mockups and thus to the design.
https://bugzilla.gnome.org/show_bug.cgi?id=644600
GJS complains when a NaN is passed in place of an integer, and
parseInt returns that from non numeric string. Pass a sentinel
that cancels the operation in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=642978
Around 2.91.90, gnome-session-save was renamed to gnome-session-quit.
This commit restores compatibility with the older gnome-session, for
those testing under GNOME 2.32 or below, by calling the DBus methods
directly.
https://bugzilla.gnome.org/show_bug.cgi?id=644591
Add the idea of an 'id' for a tab, and add a public switchTab method
so you can switch to 'applications' or 'windows'. This will be useful
for performance tests that test tab switching performance.
https://bugzilla.gnome.org/show_bug.cgi?id=644266
* Run gnome-shell-perf-helper during performance tests
* Use MUTTER_WM_CLASS_FILTER to omit all other windows
* Add new Scripting methods: createTestWindow,
waitTestWindows, destroyTestWindows
* Create a single 640x480 test window for testing overview
animation performance.
https://bugzilla.gnome.org/show_bug.cgi?id=644265
Don't enter the overview at startup, or when we we remove the
last window on the first workspace, but only when we remove a
workspace and there are windows on the other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=644541
When new messages come in we want to scroll down so that the user
sees the incoming messages. The current implementation does not work
because it relies on a synchronous allocation hack which does not work
for unmapped notifications.
Fix that by connecting to adjustment::changed and scroll whenever the
adjustment changes which equals "new messages", "new timestamp" or
"presense change", but don't interference with the user's scroll actions
i.e when the user scrolls back to read something don't scroll to the bottom.
https://bugzilla.gnome.org/show_bug.cgi?id=614977
Remove the hack from Notification.scrollTo because it is unreliable,
the caller should make sure to call scrollTo when it will actually
have the desired effect.
https://bugzilla.gnome.org/show_bug.cgi?id=614977
If we're dragging a window around and we need to reposition the windows,
due to e.g. the sliding in of the thumbnails or some other reason, then we
need to consider the original position of the dragged window, rather than
the currend drag position. Otherwise we will unnecessarily rearrange the
other windows for instance on snap-back if you moved the dragged window
past some other window.
https://bugzilla.gnome.org/show_bug.cgi?id=643786
We currently show the workspace in the overview in a rectangle
with the same aspect ratio as the screen. Originally this was
probably done since it showed the desktop, but we don't do this
anymore, and the positioning of the windows in the overview is
strictly a grid, so its not in any way related to monitor geometry.
Additionally, in the multihead case the screen aspect ratio is
very different from the overview monitor geometry, so a lot of
space is lost.
So, instead we just fill the entire inner rectangle of the overview
with the workspace. However, the way the zoom into and out of the
workspace right now is by scaling the workspace so that it covers
the entire monitor. This cannot really work anymore when the workspace
is a different aspect ratio. Furthermore the coordinates of the
window clone actors are of two very different types in the "original
window" case and the "window in a slot case". One is screen relative,
the other is workspace relative. This makes it very hard to compute
the cost of window motion distance in computeWindowMotion.
In order to handle this we change the way workspace actor positioning
and scaling work. All workspace window clone actors are stored in
true screen coordingates, both the original window positions and the
in-a-slot ones. Global scaling of the workspace is never done, we
just reposition everything in both the initial zoom and when the
controls appear from the side.
There is one issue in the initial and final animations, which is that
the clip region we normally have for the workspacesView will limit the
animation of the clones to/from the original positions, so we disable
the clip region during these animations.
https://bugzilla.gnome.org/show_bug.cgi?id=643786
When closing a workspace due to the last window on that workspace
closing, switch to the overview and show the always empty workspace
rather then just going to the adjacent workspace.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
During a drag-and-drop, our pointer grab keeps enter/leave events from
being delivered. That means that after the DND ends, whatever actor is
under the pointer won't have received the enter event it should have,
and any state or hover effect dependent on that won't work right.
By paying attention to the actors we leave and enter we can figure out
what widgets we need to call st_widget_sync_hover() on after the drag.
https://bugzilla.gnome.org/show_bug.cgi?id=640974
Showing the right click menu causes errors when ungrabbing focus in this case.
It will soon be impossible to get to the right click menu anyway when a new
notification is showing, because we are never going to show the summary
and the new notification at the same time.
Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.
The Windows pane can be switched to, but navigation within the pane is
not yet implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Fix the "panel" icon to be symbolic. Make the overview parts only show
up when in the overview, and the non-overview parts (eg, the Desktop
window, if there is one) only show up when not in the overview. Sort
the different items consistently with their locations on the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Unset this._expandedSummaryItem if it is the summary item that is being removed.
This avoids "this._sourceTitle.clutter_text is null" error.
Destroy the summary item actor only after calling _unsetClickedSummaryItem()
that disconnects from one of its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=644043
PopupMenuManager was pretending that it knew nothing about the menu's
sourceActors, while also trying to handle keynav between them. This
was a big mess, and resulted in bugs in navigation between panel menus
and the Activities button, and it totally gets in the way when trying
to add keynav to the dash (whose menu sources are arranged vertically
rather than horizontally).
Fix this up by moving the panel-specific parts to PanelMenuButton
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
It already doesn't work right, because the PanelMenuButton code
assumes that Left and Right won't be used as part of keynav within a
menu. And the gnome-panel calendar isn't keyboard accessible either,
so this isn't a regression. To be fixed later.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
To deal with different CSS in RTL locales, we used to manually add
an :rtl pseudo class to some actors. With automatically assigned
:ltr/:rtl selectors this is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
CtrlAltTabPopup was using a St.BoxLayout and relied on anchor_gravity
center for positioning. This does not guarantee correct pixel alignment,
so use a St.GenericContainer instead and do the positioning similar to
that of the appSwitcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643820
Make GSettings support optional, refactor text entry handling,
fix some off-by-one bugs in the management itself, use Params
for parsing, fix other typos and bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=642793
Currently the icon texture is only updated on style changes when
the icon size is set from CSS and differs from the previously used
icon size.
As the style change may have been triggered by an icon theme change,
textures that are created for themed icons should always be recreated;
given that this is the case for most uses (with the exception of
file thumbnails), recreate the icon texture unconditionally to avoid
complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=643738
Commit b1654af406 moved the panel positioning (and thus that of its
corners) before the panel startup animation. As the panel corners now
are mapped while the panel animation is active, the initial style-changed
signal which triggers another repositioning is received after the
initial layout and the corners end up at wrong positions.
To fix, animate the corner positions as well during the startup
animation - if anyone could actually see the animation, the corners
should animate with the panel anyway ...
https://bugzilla.gnome.org/show_bug.cgi?id=643804
Mutter really expects this, as this is how app-specified struts
happen. For instance, if the primary display is beside a taller
screen and is not positioned at the top, then we extend the struts
for the panel with the size of the unused area above the primary
monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Right now we require a strut to be as wide as the full screen to
create a TOP strut. This means that in a multi-monitor scenario (at
least if the primary monitor is leftmost) we will make the panel strut
be Meta.Side.LEFT due to the random side picking for corner objects.
This changes the width/height comparison to the primary monitor rather
than the screen to get this right. Also adds some docs about how
struts work in a multi-monitor situation.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
We need to do the initial relayout before we start up the startup
animation, and the startup animation can't hardcode the position
of the panel to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
1. disconnect destroy signals in popModal (actors can have great lifetime and then pushed again)
2. incorrect pushModal/popModal pair in overview
https://bugzilla.gnome.org/show_bug.cgi?id=64078
Increase the icon size of search results for consistency with the
application view. To account for the larger icons, only display
a single row of results per section.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Search results' meta info currently is expected to have an 'icon'
property holding a Clutter.Texture of a fixed icon size. This
property is used to implement the createIcon() function of BaseIcon,
which is used to actually display the result, ignoring the size
parameter due to the fixed icon size.
Given that all available search providers create this property for
the desired icon size using a function with the same signature, it
appears logical to replace the fixed-sized 'icon' property with
such a function, so that the icon size will be defined by the display
actor rather than the search system.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently section headers in the search view are reactive and run
the corresponding provider's expandSearch() function when clicked,
which should launch an external program displaying all search
results for the section. Unfortunately it is only implemented for
the "Settings" provider, and does not work properly (as it ignores
the search and just launches System Settings).
Also current mockups deemphasize the section header, making the
feature pretty much indiscoverable (except by accident when
interfering with swipe-scrolling).
In conclusion, the feature does not make much sense in its current
form, so remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently the total number of matches for a particular section is
displayed on the left of the section's header. While it made sense
in the old layout where it was close to the section's title, it is
now rather disconnected, and has been removed in current mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
When UPower has not yet collected enough data to calculate a time
to discharge, it will report 0 minutes. Show "Estimating..." in
that case instead.
https://bugzilla.gnome.org/show_bug.cgi?id=642753
Currently we remove a workspace when last window on that workspace closes,
which turned out to be too agressive as some apps open either a splashscreen
or a "I have crashed last time" dialog at startup.
Try to detect such apps and give them a chance to open their "real window(s)"
on the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
_ungrabActor disconnects the event signal handler but does not
check whether it is connected before doing so which can result into
an exception like:
JS ERROR: !!! Exception was: Error: disconnect() takes one arg, the signal handler id
JS ERROR: !!! lineNumber = '0'
JS ERROR: !!! fileName = 'gjs_throw'
JS ERROR: !!! stack = 'Error("disconnect() takes one arg, the signal handler id")@:0
Unfortunately the evolution-data-server client-side libraries seem to
block the calling thread. This is a major problem as we must never
ever block the main thread (doing so causes animations to flicker
etc.). In the worst case, this problem causes login to hang (without
falling back to fall-back mode) and in the best case it slows down
login until a network connection is acquired.
Additionally, in order to sanely use these evolution-data-server
libraries, GConf has to be involved and GConf is not thread-safe. So
it's not really feasible just moving the code to a separate
thread. Therefore, move all calendar IO out of process and use a
simple (and private) D-Bus interface for the shell to communicate with
the out-of-process helper.
For simplification, remove existing in-process code since internal
interfaces have been slightly revised. This means that the shell is no
longer using any native code for drawing the calendar dropdown.
https://bugzilla.gnome.org/show_bug.cgi?id=641396
Signed-off-by: David Zeuthen <davidz@redhat.com>
See commit f2158218bef0c51 in mutter. Basically, we need
to grab org.freedesktop.Notifications before anything else
in the session gets started.
Note: I intentionally removed the Util.killall bits. I believe that
for notification-daemon at least, if we specify
DBUS_NAME_FLAG_REPLACE_EXISTING, we'll take over the name. Not sure
about notify-osd; if that's still a problem, then what we need to do
is add killing (and possibly respawning) of notify-osd to
"gnome-shell --replace", and not have it embedded randomly in a JS file.
https://bugzilla.gnome.org/show_bug.cgi?id=642666
The DBus JS binding will complain if the signature of a method
or of a signal is undefined, so we need to define it even if it
is an empty string, and we need to use the correct property name
for signals.
https://bugzilla.gnome.org/show_bug.cgi?id=643374
For applications with no proper desktop file, the window icon is
used as application icon in the tab switcher, but it won't have
the correct icon size. The current approach is to add additional
padding to these icons - the size turns out inconsistent with
other icons, but the icon appears sharp. For the dash it has been
decided that unsharp icons are less evil than differing icon sizes,
so icons are scaled up to the "right" size - for consistency, do the
same in the alt-tab switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643300
Mainly due to StTextureCache's way of handling fallback icons, an
implementation of BaseIcon.createIcon() may return an icon smaller
than the requested size. Given that BaseIcon is not used for isolated
elements, but rather for groups of related items (App view, Dash,
Search Results, ...), having some elements end up with the wrong
size is more annoying than having some elements end up ugly due to
scaling, so explicitly enforce the requested icon size.
https://bugzilla.gnome.org/show_bug.cgi?id=642043
As gnome-shell now switched to use the menu file from gnome-menus,
we no longer have direct control over category names. If such a name
contains unescaped markup, the shell will crash when trying to create
the filter label, so make sure to escape markup in category names.
Fix a typo in panel.js, and ensure that all variables used in
functions are scoped to the block (using let), to avoid polluting
the global namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=643210
Rather than connecting to stage::capture-event and then trying to
guess whether or not a given key-press should be handled by us or not,
handle the end-search-on-Escape case from entry::key-press-event
(since it only makes sense when the entry is focused anyway) and the
start-search-on-printable-key case from stage::key-press-event (which
will only get the events that no other actor wanted for itself).
Similarly, do exit-overview-on-Escape and switch-panes cases from
stage::key-press-event, rather than
viewSelector.actor::key-press-event, so that they will work correctly
even if the keyboard focus is somewhere else. (Also fix a longstanding
bug in the pane-switching code, which was supposed to be disabled when
a search was active, but was checking a non-existent variable.)
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The search entry was taking a sort of grab when it was in the
focused-but-empty state, and would eat up most events for other actors
(except, confusingly, for panel actors). The only bit of "modality" we
really need here is that the entry is supposed to go back to the
unfocused state if you click somewhere outside it when it was in the
focused-but-empty state. So do that.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The division of labor between the two was quite muddled. Rather than
try to invent a clean distinction of what belongs where, just merge
them together.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
When the user cancels the drag while hovering over a window the timeout
handler will throw an exception because the drag actor will be destroyed
at this point.
Fix that by removing the timeout in _onDragEnd.
The xdnd timestamp gets updated on every xdnd-position event,
so while waiting for the window timeout to fire we need to make sure we
update the timestamp when getting on motion to activate the window
with the correct timestamp.
Commit 259c84ed9a refactored out HotCorner into its own class
and added this line and a variable, but it was left behind
when the variable disappeared in commit 7cf311dac0.
See https://bugs.freedesktop.org/show_bug.cgi?id=27788#c1 for details
about the problem this patch is solving
In particular, we should never bring up the dialog if there is no
password on the account. While this sounds like a weird corner case,
it's not.. the Live CD, for example, does not have a root password.
This also avoids the initial dialog resize.. before the patch the
authentication dialog appears and a split-second later an StEntry
widget is added.
Also print out more diagnostic information if showing the modal dialog
fails. Also add a comment about how to easily make this happen.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Currently the panel is positioned from main.js, move that code into
a method in panel.js instead and call it from main.js, which is
consistent with what we do for the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=643064
This is required since we can have chrome on multiple monitors (due to
per-monitor hot-corners).
Windows are primary associated with the monitor that their center is on.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
This is needed so that we can have several instances, one per
monitor.
This also makes the hot corner environments a container which
contains the corner.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
In the mockups the bottom border of active panel buttons is drawn
on top of the panel's border. To get this effect, move the panel
border into the background, so that it is not subtracted from the
vertical space given to the buttons. Adjust the drawing of the rounded
corners to reflect that change.
https://bugzilla.gnome.org/show_bug.cgi?id=643001
This allows PolicyKit applications to disambiguate between when the
authentication dialog is dismissed versus when authentication fails
(e.g. the wrong password has been entered).
See https://bugs.freedesktop.org/show_bug.cgi?id=30653 for more
information.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We never get enter events anyway due to the menu code, and if
the user clicks on a non-menu the menu is removed and ungrabbed
before the target actor gets the event anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Currently the menu has a hardcoded width which result into the hover
effect of the "Open Calendar" item being "cut off" in the middle rather
then reaching to the edge.
To be consistent with other menu items, make it expand to fill the available
space.
This is special menu item that can alternate
between two choices when you hit the alt key.
It will be useful for getting a hybrid
suspend/power off menu item.
https://bugzilla.gnome.org/show_bug.cgi?id=636680
PopupMenuManager relies on menus being added in the order of the
menu buttons they are attached to, so defer adding the user status
menu until the status icon menus have been added to make the manager
happy.
This patch modifies MessageTray behaviour so that normal (not urgent)
notifications are not shown when the user is Busy (they're sent
immediately to the Summary area). When status is then changed,
notifications still pending are shown again.
Additionally, when status is modified from Idle to anything other than
Busy, the message tray is forced open for 4 seconds, so that summary
icons are visible.
https://bugzilla.gnome.org/show_bug.cgi?id=617225
A PolicyKit Authentication Agent is a construct used to authenticate
one or more identities. See the PolicyKit documentation for more
details on authentication agents and how PolicyKit works:
http://hal.freedesktop.org/docs/polkit/
Since gjs does not support subclassing a GObject class from Javascript
code, we bring in a native class to bridge the VFuncs to GObject
signals. Additionally, this native class also queues up authentication
requests so the user of the native class only has to deal with a
single outstanding request at any one time.
The file js/ui/polkitAuthenticationAgent.js introduces a singleton
that listens for authentication requests via the native class. This
singleton uses the PolkitAgent machinery to do the actual heavy-weight
lifting required for authentication (essentially a PAM conversation).
We currently don't allow the user to pick the identity to be
authenticated.
https://bugzilla.gnome.org/show_bug.cgi?id=642886
Signed-off-by: David Zeuthen <davidz@redhat.com>
Complex popup menus require the ability to manager sequences of items
as "sections", to which you can add and and remove items, as well
as hide and show.
PopupMenuSection does exactly that, leveraging the existing machinery
for submenus, but without being exposed as a submenu to the user.
Also, make getMenuItems() private, since it is used for different things
now and may change semantics in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
Make all subclasses of PopupMenuBase accept a params argument, which
can be used to make the item non reactive, not responsive to hover
and, as a new feature, with a different style class.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
If the Shell is started with HighContrast enabled, it will never
see another value for the GSettings keys. In that case, we just
reset to the default.
https://bugzilla.gnome.org/show_bug.cgi?id=642641
We need the view selector to extend all the way to the right edge of the
monitor, so size and position the view selector in a way that the sum of
its X position and its width add up to the primary monitor width.
https://bugzilla.gnome.org/show_bug.cgi?id=642834
So far transitions do not work for the custom drawn corners, so to
avoid a visible glitch when transitioning a button in the panel corner
while updating the style of the apparently attached corner instantly,
remove transition of those panel buttons until we make it work for the
custom drawn parts as well.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
Current mockups show the panel curving downwards at the edges to
frame the work area and look awesome. Implement those as separate
actors to not affect the struts set by the panel, and synchronize
their state with the corresponding panel buttons so they blend in
with the panel. It might be worth considering whether the corners
should be hidden with maximized windows on the current workspace,
though this might affect the illusion of them being part of the
panel. As the corners don't affect the input region, the small
overlap with windows might not be too bad after all.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
The groups at the panel sides use different left/right padding, so
a slightly different CSS is required for RTL locales. Add :rtl
pseudo classes as necessary and adjust the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
We now use a border image on active panel buttons to underline the
button's content. As the property does not affect the content's
allocation, the app icon ends up being drawn on top of the border
image. To prevent this, use a custom property to clip the bottom of
the app icon when the button is active.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
While related to the status area, the user status button is clearly
not a status icon, and it does not make too much sense in
startStatusArea(), which is about filling the status area with
icons. Also, the status icon container is added to the panel in
the constructor, in fact, the user status button is the only "toplevel"
panel element which is initialized elsewhere. Not a crucial change,
but makes for a nice read anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=642697
When we are dragging a window over its current workspace or workspace
thumbnail, we show show "no drop possible" feedback instead
of "move here" feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=642329
We don't necessarily get a syncStacking call when an actor is added
at the top of the workspace, so make sure to set the stackAbove value
for it correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=642329
'Search your computer' is problematic for various reasons:
- it specifies the kind of device
- it focuses on local search (while we also do web search)
- it does not advertise the instant search functionality
Change the hint text to 'Type to search' as proposed by Allan Day.
https://bugzilla.gnome.org/show_bug.cgi?id=642287
This starts saving lookingGlass history in gsettings, and also adds
the ability to clear the text field by pressing 'down' on the last
entry, like the run dialog and readline allow.
https://bugzilla.gnome.org/show_bug.cgi?id=642237
We try to position the boxpointer centered above the calendar,
which swaps position with the events list when using a RTL locale,
so make the menu alignment dependent on the text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=642721
As the dash uses different widths and radii for left and right
borders, we need to use different CSS when it is positioned at
the right of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=642721
- When tweening a workspace to collapse it, round the multiplied
height so that we don't change other workspace sizes via rounding
differences.
- Use separate horizontal and vertical scales, so that every thumbnail
has the same horizontal scale.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
Allow defining a "porthole" that is the visible area of a workspace
thumbnail, and use this to clip the portion under the panel off the
workspace thumbnails. (This is wrong for fullscreen windows, but not
very wrong, and hopefullly the few missing pixels will be
unnoticeable.)
https://bugzilla.gnome.org/show_bug.cgi?id=641880
Because the overall parent allocation width immediately when the workspace
count changes, we were sometimes drawing the indicator in the wrong place
in the indicator animation that proceeded the remove-workspace animation.
Fix this by tweening only the Y position of the indicator and computing
the X position and size in our allocate() method. This also is considerably
simpler than switching the indicator between fixed position and geometry
managed.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
Rather than killing the workspace indicator indicator when we remove
workspaces because the source and target locations might have changed,
do it as a separate first step. This provides a better explanation
than doing it simultaneously with the addition/removal or not at all
and also keeps our computations simple.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
When we animating the scale for the thumbnails, the border and
background should wrap around the current size of the thumbails.
The technique that we are using to animate the scale breaks that
since we don't animate the overall size of the thumbnails box -
we just animate our child actors within the allocation.
To fix this, switch from drawing the background by packing in another
container to drawing the background with a separate actor that
is under the other actors and allocated by our custom logic.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
To explain to the user what is happening, instead of abruptly changing
updating the workspace thumbnail list, slide thubmnails in and out
as they are added and removed.
To implement this, we track a state for each thumbnail and when things
change go through a process of first sliding removed thumbnails out,
then ollapsing the left-over spaces and rescaling the thumbnails, then
finally sliding newly added thumbnails in.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
For historical reasons, StEntry always did hover tracking when you had
visible hint_text, even if track_hover was FALSE. Remove that special
case, and make entries track hover just like all other widgets do.
If we actually needed to distinguish hovered-with-hint-text from
hovered-without-hint-text (which, at the moment, we don't), we could
do that by setting separate CSS for :hover and :hover:indeterminate.
https://bugzilla.gnome.org/show_bug.cgi?id=642483
The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
If you left the overview immediately after entering it (either
intentionally or due to a bug), the app menu would mistakenly end up
hidden due to flaky interaction between its show() and hide() methods.
Based on a patch by Dan Winship <danw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=641117
When we have more thumbnails than can fit in the vertical space, scale
them down. This is implemented by using a generic container so we can
compute positions and sizes on the fly and do the appropriate
width-for-height behavior.
The usage of clutter constraints to position the indicator is droppped
since it less complicated to just position the indicator in the right
place ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The scale we zoom to in the "zoomed out" mode depends on the width of the
controls area. Once we rescale the workspaces dynamically, we'll need to
update the zoom scale as we add and remove workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
We will change the workspace thumbnail size as we get more thumbnails; it doesn't
really make sense to always show 1/5 of the thumbnails how big or small they are,
so instead show a CSS-configurable length.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Fix a bug in the computation of the zoomed-out scale and use a StBin
instead of an unnecessary StBoxLayout. Using the StBin will allow
correct width-for-height behavior for the controls.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Add WorkspaceThumbnail.ThumbnailsBox to handle managing the array
of workspace thumbnails; the logic will get more complex as we add
scaling and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The settings in org.gnome.desktop.default-applications.at
have been removed, use the corresponding settings in
org.gnome.desktop.a11y.applications instead.
gsettings-desktop-schemas had two conflicting settings for showing
the magnifier: 'show-magnifier' in org.gnome.desktop.a11y.magnifier
and 'screen-magnifier-enabled' in org.gnome.desktop.a11y.applications.
The former has been removed in favor of the latter, so adjust to this
change.
Add the machinery to cancel the notification when a new playing a
new one (wrapping ca_context_cancel), then use it when scrolling
the status icon.
Not doing it for the slider because it causes noise, either with the
keyboard, with mouse drag or with mouse wheel.
https://bugzilla.gnome.org/show_bug.cgi?id=633667
The original icon doesn't exist, which results in empathy summary
items in the tray showing no icons (invisible) at all. With this fix
users can now at least see where the icons are (they are no longer
invisible).
https://bugzilla.gnome.org/show_bug.cgi?id=639468
As Main.overview is now usable from the view selector's constructor,
move the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
To enable find-as-you-type when entering the overview and disabling
it when leaving, we used a chain of functions calls from ViewSelector
over SearchTab to SearchEntry. As find-as-you-type should be enabled
while the overview is shown, the activation/deactivation can be
handled entirely by the SearchEntry itself by tying it to the entry's
visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
As Main.overview is now usable from the dash's constructor, move
the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
The Overview does not only hold the different elements visible in
the overview, but is also a central point to manage drag signals.
As objects which are constructed in the overview constructor cannot
access Main.overview (as its constructor has not finished yet), we
use misnamed show/hide methods to work around this limitation, which
are called when entering/leaving the overview.
A better way to handle this problem is to remove the limitation
altogether by splitting the overview constructor between internals,
which remain in the constructor, and more complex objects which
need to access Main.overview, and whose initialization is moved
to a public init() function which is called by main.js after the
overview has been constructed.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
This patch fixes the summary notification reappearing if you click on the
summary item to hide it and hover away. It also ensures that when you click
on any summary item which doesn't correspond to the summary notification
being shown, a new summary notification will replace it right away.
What used to happen is that we'd unset the clicked item in _unlock() that
was called when the focus was ungrabbed because the user clicked outside
of the summary notification, but then would have this._clickedSummaryItem
be null in _onSummaryItemClicked() , and set it to the clicked item all
over again. This patch ensures that we unset the clicked item only when
it is necessary.
We also needed to add the code to call _updateState() again to show a new
summary notification when a previous one was hidden, but
this._clickedSummaryItem was set.
https://bugzilla.gnome.org/show_bug.cgi?id=642005
Follow-up to commit 09717aae58 so
title changes also support markup instead of the ugly "<i></i>"
status.
Additionally, make sure to escape the contact's title as that
may accidentally contain unsafe markup or characters.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
We were adding pango markup to the message in ContactManager.setPresence,
but weren't correctly marking the message as containing pango markup,
allowing for uglyness such as "User is <i>away</i>." being shown to the
user.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
As the dash is one of the primary drop targets for dragging application
launchers, it's reasonable to use the dash icon size for app icons'
drag actors, especially with the larger size now used in the application
view.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
As elements in the dash are scaled to accommodate a growing number
of items, the icon size used may end up rather small. In that case,
dragging items to the dash which are significantly larger than items
in the dash is getting clumsy, so it makes sense for some components
to synchronize the size of drag actors with the currently used icon
size in the dash. To enable other components to do this, make the icon
size a public property.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
- Center the icon texture in the area allocated for it, and always give
the nominal size - avoid off-by-one scaling if the parent allocated
a little less or more size than we wanted.
- Use Math.floor() when centering horizontally to avoid allocation
at a half pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=642124
Make calling workspace.setReservedSlot(null) do nothing if the slot was
already null; this improves efficiency and more importantly chills out some
weird reentrancy at the end of drag and drop that removes a window from
a workspace.
We were properly accounting for the fact that an ancestor of the
parent could be scaled rather than the parent itself when computing
the snap-back scale, but directly using parent.scale_x for the
snap-back location.
https://bugzilla.gnome.org/show_bug.cgi?id=642117
A right click was propagating through to the parent actor meaning
that a right click would activate the workspace twice and leave the
overview instead of just switching to it.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
If you want to select a workspace and go there, having to go back to
the main part of the window selector and click on a window is annoying,
so make a second click on the active workspace go to the main view.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
Some recent painting-efficiency fix broke the inspector, which
accidentally depended on things getting repainted too often, and so
was failing to highlight things properly now. A simple queue_redraw()
fixes this, but while I was there, I decided to port the drawing hook
to JS as well, since all the necessary parts of cogl work fine from
JS.
https://bugzilla.gnome.org/show_bug.cgi?id=642058
That way it can be used when other components of the message tray need to
grab focus, such as the summary bubble with multiple notifications or the
summary item's right click menu.
https://bugzilla.gnome.org/show_bug.cgi?id=641810
The view might get mapped before the filters have been added, so
trying to reset to the "All" filter will throw an exception. Fix
by only do the reset if the filters have been initialized.
When switching to the app view, it is unlikely that a user is
going to select an application from the same filter list as the
last time the view was used, so reset the view to the "All" filter
on switch.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
When switching to the application view, the view is still scrolled
to the position it had when left previously. Given that it is rather
unlikely that the application the user wants to select is located close
to that position, it appears beneficial to start at a predictable
position, so make sure that the scroll position is always reset to
the top.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
The default state of the switcher is constructed but not visible,
so create it that way.
This fixes a bug where if we created the switcher but didn't show it
or use it we'd end up with an empty, odd looking switcher.
We already skip animations for item additions/removals while the
overview is hidden or when initially filling the dash (to avoid
an odd zoom effect when showing), apply the same logic to animations
of icon size changes.
If a window is closed, the list of running applications may change
while the overview is hidden. Animating dash changes is pointless
in this case, so update the dash without animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The dash is created empty and the initial set of items is added
before it's shown for the first time. As the additions of items
is now animated, this results in a slightly odd effect when all
items zoom in at once. So special-case the first time _redisplay()
is called and skip animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
In general, all changes in the shell interface should be backed
by animations to give the interface a more natural feel and provide
feedback of what's happening. Currently the dash violates that
principle, as items simply appear/disappear or change size abruptly,
so add animations for application list and icon size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Clutter containers only take their children's size into account, but
not their scale. As we want the dash to change its size smoothly
when zooming items in/out, we wrap each item in a custom container
which does consider the child's scale.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
When the list of applications in the dash changes, all items are
removed and new ones added. While this approach is nice and simple,
it does not work if we want to animate changes. So rather than
replacing the old list of applications with the new one, figure
out the changes and only apply those.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Previously the icon size was only adjusted due to changes in the list
of application icons displayed, not when showing or hiding the remove
target. As a result, the remove target could end up cut off, so take
this case into account and adjust the icon size when showing or hiding
the remove target.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The current approach to adjust the icon size of dash items is rather
expensive: the size of each item is changed from largest to smallest,
until the height of the dash fits the maximum available height, so
quite some ClutterTextures are created and disposed.
A better approach is to calculate the required size beforehand and
only change the icon size when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
With the current dash layout of a single column, nearly every icon
label ends up ellipsized, even at the largest allowed icon size.
Not showing any labels appears to be the cleanest approach in this
case, so disable them in the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Currently there is a serious problem with ellipsization in various
parts of the overview. While wrapping the label or giving it more
space may be appropriate approaches for the application view, neither
works very well for the dash - possibly the best option there is to
not show the label at all.
So add a constructor parameter to BaseIcon to allow hiding the
label.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
With workspaces now being stacked vertically, the horizontal
indicators in the workspace switcher are rather odd. There are
some designs for an improved workspace switch animation, but
it may take a while to implement them, so for now just change
the orientation of the existing switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=641931
Point the arrow to the center of the sourceActor's content box, rather
than its allocation, in case it has asymmetric padding (as the
rightmost message tray summary item does).
https://bugzilla.gnome.org/show_bug.cgi?id=641728
Commit c86a977564 removed :pressed from the list of styles which
highlight panel buttons, so the button highlight is now lost when
mousing over menu items. This is not the behavior we want, the
buttons should keep their highlight while being "active". Rather
than adding back the pseudo class to the CSS, let buttons use the
:active pseudo class when the menu is open, which makes more sense
than :pressed anyway.
The status icon should always be visible if more than two layouts
are configured. The settings key which was used to enforce hiding
the icon in this case as well has already been removed from the
g-s-d schema, causing an error on startup.
Intead of using a St.Group and tweening the position of the controls
actor, use a St.GenericLayout and tween a Javascript property. This
allows us to more reliably track the height of the overall workspace
display and propagate it to the controls actor.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With workspace thumbnails, we don't switch workspaces when dragging windows
between workspaces or adding new workspaces, so we also shouldn't switch
on launch.
* Add workspace parameters to shell_doc_system_open(),
shell_app_activate, shell_app_open_new_window()
* Pass a 'params' object when activating items in the overview with
two currently defined parameters: workspace and timestamp. (timestamp
is only implemented where it is easy and doesn't require interface
changes - using the global current timestamp for the shell is almost
always right or at least good enough.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
At the end of a drag operation, we would invoke the code to slide the
controls in (because we were no longer DND'ing and not hovering) and
then immediately afterwards invoke the code to slide it back out when
we got the ENTER event from the end of DND. While the immediately
overridden tween probably won't have any visible effect it's better
to avoid this, so wait to update the zoom state until BEFORE_REDRAW.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With automatic workspace management, explicit controls to add and
remove workspaces are no longer necessary. We also can remove the
use of addWorkspace for middle-button-click on a launcher since
launching on the last empty workspace will do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With workspace thumbnails, we want to make workspace switching
something that happens largely under the users control, so don't
switch to newly added workspaces in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Add workspace thumbnails to the workspace controls area. The user can
click on the thumbnail to switch workspaces and can also drag windows
out of the thumbnail to other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Moving the base tracking of restacking to WorkspacesDisplay will allow
us to use it to update stacking in the workspace thumbnails as well as
in the main workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Instead of having a separation between popping the controls out on hover
and zooming out for DND, always do both at once. This is necessary because
when we added workspace thumbnails the controls will get bigger, so we need
to make sure we zoom out far enough so that the windows don't overlap the
controls.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
The new plans for a row of workspace thumbnails on the right side of the
overview means that the mental model we present to the user will be
vertical, so switch the Metacity workspace layout to be vertical and
adjust the keybinding handling, animations, and workspace layout in
the overview to match.
(This commit does not change the workspace switching indicator pending
finalization of what we want to do with that - it still shows workspaces
arranged vertically.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
St.Button 'clicked' signal now has two arguments, and because we are also
passing an action id as an argument to the _onActionInvoked() callback,
we need to have the number of the signal arguments reflected accurately in
the function arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=641809
This makes the animation feel more stable and keeps the left-most item expanded
when you move the mouse to the left in the tray.
The following behavior details are implemented by this patch:
- we wait to collapse an expanded item till after the tray is hidden if
we are hiding the tray
- we don't collapse an expanded item if the summary notification associated
with it is being shown, unless a different summary item is hovered over
- we don't consider the mouse hovering over a summary notification as
hovering over the tray, which allows us to collapse an expanded summary
item if it is not associated with the summary notification being shown
https://bugzilla.gnome.org/show_bug.cgi?id=636930
For historical reasons, we had both StClickable and StButton, which
were nearly identical. StButton was more widely-used, so keep that and
port all StClickable users to that.
https://bugzilla.gnome.org/show_bug.cgi?id=640583
It doesn't currently work, so hide it for now.
It's not clear it's going to stay around long term,
anyway. If it doesn't we can delete the code, then.
Otherwise, we can add the code back when we have
something that works.
https://bugzilla.gnome.org/show_bug.cgi?id=636680
Commit 91d8a32f25 let WindowClone forward the size-changed signal
of the "real" window, disconnecting the signal handler when the
clone is destroyed. In case the clone was destroyed due to the
MetaWindowActor being closed, this results in a warning
(gsignal.c:2392: instance `0x2a3fac0' has no handler with id `2955').
Handle the case where the original window is destroyed before its
clone.
1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
on the children to be removed. In the rare cases where it might be needed
the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781
In non-US locales, Monday is generally considered the first day
of the week. Take this into account when building the event
lists displayed under "This week"/"Next week".
https://bugzilla.gnome.org/show_bug.cgi?id=641049
Signed-off-by: David Zeuthen <davidz@redhat.com>
When the current day does not exist in the next/prev month (like 31 Feb),
the next/prev buttons end up skipping the month.
Fix that by going to the last day of the month instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641067
There are multiple code passes that can result in Notification::destroy()
being called, such as a notification being closed by the application
when it exits and the associated source being removed at the same time.
However, we should only emit 'destroy' for the notification and
do the associated work once.
Notification::destroy() now takes 'reason' as an optional argument.
Calling Notification::destroy() directly when connecting to 'destroy'
on Source, as we did before, was inadvertently passing 'source' as an
argument to the function.
https://bugzilla.gnome.org/show_bug.cgi?id=640976
This fixes emitting NotificationClosed for resident notifications
that are clicked, but are not actually destroyed.
This also ensures that we emit NotificationClosed in all cases when
a notification is destroyed, which can happen when:
- a non-resident notification is clicked
- an action is invoked on a non-resident notification
- an application the notification was associated with is focused
- a transient notification is done showing
- a notification was requested to be closed by the application
- a tray icon the notification was associated with is removed
https://bugzilla.gnome.org/show_bug.cgi?id=638071
Windows may change their size while the overview is open, e.g. when
switching panels in the control center. Make sure that the preview's
position and overlay are updated in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=640560
On button-release, a threshold is used to determine if the gesture
should be considered a click and thus ignored. While the drag is
active though, the controlled actor is dragged immediately. As a
result, dragging by a tiny amount does not trigger a snap back when
the action is interpreted as a click. As a fix, do not update the
dragged actor's position until the same threshold is passed.
https://bugzilla.gnome.org/show_bug.cgi?id=640494
The main overview group starts capturing events on button-press
events to implement swipe-scrolling. While reactive children of
the group which handle both button-press and button-release events
don't trigger swipe-scrolling, children that only rely on
button-release have stopped working - at least the primary/secondary
icons of the search entry are affected. While the capture handler
already checks the pointer movement between press and release to
determine whether the action should be considered a click rather
than a drag, it still blocks the release event from propagating.
Instead, only block release events for drag actions, but not for
clicks.
https://bugzilla.gnome.org/show_bug.cgi?id=640493
When aiming for the thumbnails with the mouse one might cross an
icon by accident which causes the thumbnail list to be closed, which is
frustrating.
Fix this by delaying the icon activation when the thumbnail list is
open.
https://bugzilla.gnome.org/show_bug.cgi?id=636650
With general support for swipe-scrolling in the overview, there is
no reason to limit the behavior to workspaces. It is equally useful
for scrolling through the grid of available applications, so enable
swipe-scrolling for the app view.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
The workspaces view allows to drag the active workspace to swipe-scroll
to the next or previous workspace. While this behavior can come in handy
in general, there are good reasons to move the functionality to the
overview:
- Finding a spot on a workspace to start a drag can be hard,
especially when the workspace contains a single window
- With the new layout, workspaces have no visible border, making
it hard to predict where a drag can be initiated
- The same behavior is equally useful for other elements
So add setScrollAdjustment() to the overview, which allows setting
an adjustment controlled with swipe-scrolling (either horizontally
or vertically); only a single adjustment can be controlled at a
time. A swipe-scroll can be initiated on any part of the background that
is not occupied by a reactive actor. For cases where further control
is needed, 'swipe-scroll-start' and 'swipe-scroll-end' signals are
emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
Introduce a generic framework for on/off indicators that are shown
in the panel, next to the system status area, and use it for
showing the status of modifier keys.
https://bugzilla.gnome.org/show_bug.cgi?id=600771
Drag monitor functions are supposed to return a value, but
_onDragMotion() does not always do so. Add the missing return
value and remove unnecessary else.
As Gdk.Device.get_state() does not work properly from Javascript,
we used to block it in the environment. The method now has been
annotated with (skip), causing shell to crash on startup as only
existing methods may be blocked.
Just remove the block in question, as the annotation prevents the
use of that method anyway.
Currently we reset the timeout on every mouse movement which means
the user has to keep the mouse at the exact same position for 1.25
seconds.
Be more tolerant and allow the user to move the mouse over the
window without reseting the timeout, which should make activating
windows easier.
https://bugzilla.gnome.org/show_bug.cgi?id=638896
This fixes the problem of chat notifications collapsing and then expanding
again when receiving multiple messages in the expanded new notification.
https://bugzilla.gnome.org/show_bug.cgi?id=629557
g_settings_schema_new() aborts if the requested schema is not found,
so the previous approach of handling the case of unstable nautilus
not being installed did not work.
Instead, remove the use of the setting altogether - the original intent
was to not have separate items for Desktop and Home in the places
section if the nautilus key was set. As the section has been removed
anyway, the impact of always adding the desktop folder is minimal
(e.g. searching for "desktop" will match the desktop folder even
if it's set to the home folder).
The latest development version of nautilus has been ported to
GSettings, which we now use as well for the desktop-is-home-dir
preference. Obviously, the required schema is only available if
a recent enough nautilus version is installed. Instead of adding
yet another module to the moduleset, catch the exception and
ignore the preference in case the schema is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=639689
'Places' follows the nautilus preference of whether the Desktop
should be a separate directory or the home folder should be used.
Nautilus has been ported to GSettings a while ago, so follow suit.
https://bugzilla.gnome.org/show_bug.cgi?id=639689
GenericDisplay used to provide a common base class for places and
recent items, none of which exists anymore. As of current mockups,
display items in "Finding and Reminding" should be based on
BaseIcon / IconGrid instead.
Currently recent items only show up in search results. It is planned
to bring them back in the context of "Finding and Reminding", but
the UI in the corresponding mockups differs significantly from the
removed UI, so that it doesn't seem useful to keep it around.
Layout items in the menu overwrite PopupBaseMenuItem.activate(),
so the menu stays open when selecting a layout from the menu.
Chain up to the parent class' method to make the items behave properly.
https://bugzilla.gnome.org/show_bug.cgi?id=639474
When an error message is displayed the run dialog
pops to the new height instantly. It needs a
a transition.
This commit makes the dialog quickly grow to its
ultimate height, making room for the error message,
before showing it.
https://bugzilla.gnome.org/show_bug.cgi?id=637187
Now that we have a modalDialog base class in gnome-shell,
it makes sense to use it for the run dialog.
Note, the run dialog doesn't currently have buttons, so
it isn't exercising all the API of the base class.
https://bugzilla.gnome.org/show_bug.cgi?id=637187
This is a base class to make it easier to
gain a consistent look for system modal dialogs.
It handles creating a darkened backdrop behind the dialog, setting
up buttons in the dialog, keynav, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=637187
Right now popModal() passes global.get_current_time() for
its begin_modal() call. global.get_current_time() is the
timestamp of the last gdk or clutter event processed by the
shell's mutter process. These values could potentially be
be too stale to use if pushModal() were to get called in
response to an event by another process.
This commit changes pushModal() to have an optional timestamp
argument, which can be used to associate the call with the
event that initiated it.
https://bugzilla.gnome.org/show_bug.cgi?id=637187
