With fallback mode gone, we can no longer rely on gnome-screensaver
being installed. Rather than handling three different cases (GDM,
gnome-screensaver, no lock), disable the lock functionality when
not running under GDM.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
With fallback mode dropped, we can no longer rely on gnome-screensaver
to be installed, so we'll have cases where we are unable to lock the
screen. The user menu should not show the "Lock" item in this case,
but as UnlockDialog includes UserMenu, we cannot use the existing check
without creating a circular dependency; move the function to a more
generic place to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
We currently resync the stacking order of the two key frames
every iteration of the animation. This is costly and unnecessary.
This commit ensures they're stacked properly up front and doesn't
touch them after that.
https://bugzilla.gnome.org/show_bug.cgi?id=694993
Rather than expose a dizzying array of methods related to managing
state that require infecting every user of the overview methods, try
to do the sensible and smart thing internally. Now, the overview
itself tracks when XDND drags start, and simply calling show, hide or
toggle while an XDnD drag is in effect will show the overview, and
will only take the grab until after the XDND drag ends.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
We currently call the session updated handler as soon as
the session modes are read. This handler sets up keybindings
for leaving the overview (if a user session) and shows the
login dialog (if a gdm session).
We can't do the latter until the stage is mapped because it
takes a grab, and we don't need to do the former until the
user goes into the overview.
This commit defers processing session updates until the
the layout manager says start up is prepared.
It fixes a race condition at login screen startup now that
we don't show the stage right away.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
This cleans up the code considerably, and makes it so that
one path creates all hot corners for all monitors. Why this
wasn't done originally, I have no clue...
The one complication is debouncing if the button and hot corner
are triggered in rapid succession, so we just move this tracking
to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
For the HotCorner, we want to have different logic for tossing out
specific events based on the grabbed state, etc. so make us have
to pass in an event filter callback.
For the hot corner case, we want to have the pressure apply both in
and outside of the overview, so we need to move this to the user. At
the same time, use keybinding mode math that's more like what's used
in filterKeybinding.
While it may seem like an abuse of the KeyBindingMode API, it may
become more reasonable if one thinks of the pressure barrier as a
binding of sorts, just applied to the mouse. If a ButtonBinding API
was added to mutter, I think we'd use the existing KeyBindingMode
infastructure there as well.
Ensure that the pointer leaves the barrier before we trigger again.
For the message tray case, this doesn't matter much, as the trigger
won't have any effect after the grab is taken, but in the overview
HotCorner case, this ensures that we don't trigger the overview
transition many times simply by holding pressure against the hot
corner, which is easy to do accidentally.
Instead of sometimes having an event source and sometimes not, use
the empty event source when the session mode says the calendar is
disabled. This way, the code can assume an event source object and
avoid checks.
https://bugzilla.gnome.org/show_bug.cgi?id=641383
Check if the event source is currently doing an async call, and prevent
UI updates in that case. This avoids a flash of "No updates" when switching
months.
https://bugzilla.gnome.org/show_bug.cgi?id=641383
SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.
This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.
https://bugzilla.gnome.org/show_bug.cgi?id=693907
Toggling the overview during the startup animation reportedly
causes stuck grab and other odd behavior.
There's no reason to handle toggling the overview during this
time anyway.
This commit defers that handling until after startup.
https://bugzilla.gnome.org/show_bug.cgi?id=694837
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the copy action for password
entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
We always leave the workspace switcher zoomed out when we can assume
that the user is actually making use of workspaces. For the default
dynamic workspace behavior, we make this assumption when more than
two workspaces are in use (e.g. at least two workspaces contain windows
plus an empty one at the end). However this test does not make sense
when using static workspaces - in that case, not using workspaces
would be indicated by a workspace number of 1 (in which case the
entire switcher is hidden completely), so add a check for dynamic
workspaces to the condition.
https://bugzilla.gnome.org/show_bug.cgi?id=695126
Currently both the app switcher and the thumbnail list divide items
first into two groups (based on whether the item is located on the
current workspace or not), and then sort each group individually
by MRU.
The resulting behavior is often confusing, e.g. when using alt-tab
a second time does not switch back to the original window when the first
invocation involved a workspace switch and the workspace contains
windows of more than one application.
Instead, make the behavior more predictable by sorting both lists
strictly by MRU.
https://bugzilla.gnome.org/show_bug.cgi?id=661156
Shell modal dialogs can take their action on a certain key's
key-release-event. For example on <enter> the affirmative action is
usually run.
Make sure that the key was also pressed on the dialog and we're not
seeing a spurious key-release-event from a key that was pressed before
the dialog was displayed.
https://bugzilla.gnome.org/show_bug.cgi?id=692937
It is possible that a session survives after closing, if any processes
(usually PulseAudio and GConf) are still alive at the end. In that case,
ignore it, as the user is already logged out and there is nothing to lose.
https://bugzilla.gnome.org/show_bug.cgi?id=695002
Implement a basic OSD popup that shows an icon and optionally a label
and a fill level. It is based on the existing OSD implementation in
gnome-settings-daemon, which it will replace.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Right now we take a still frame of the desktop before showing the
start up animation. This gives us an animation over what was
there before startup.
That's not actually desirable when restarting the shell. We don't
want to animate over undecorated windows, we really want to animate
over the noise texture.
This commit drops the still frames in favor of the noise texture.
https://bugzilla.gnome.org/show_bug.cgi?id=694326
Previously, the overview BoxLayout was sized and positioned explicitly
using the primary monitor coordinates, as its parent was at 0,0 and
with a fixed layout manager. Now we use a bin layout, so we need to
position and size the stack actor, and set the overview boxlayout to
expand.
Take also the occasion to use a MonitorConstraint instead of handling
position and size manually.
https://bugzilla.gnome.org/show_bug.cgi?id=694969
We used to clip the overview group to prevent the dash from sliding into
neighbor monitors, but now it moved to the groupStack, so we must move
the clip too.
https://bugzilla.gnome.org/show_bug.cgi?id=694970
This filters out resident and transient notifications in the normal
case, but just returns the number of unread messages for the Telepathy
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=687787
We generally want view content centered, in particular where the
view itself is symmetrical. So move the dash to a separate layer
and use a placeholder to account for its size when showing the
window picker, which is the only view where it doesn't make sense
to center the content.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
Commit 43ed66cf26 changed the toplevel overview actor, so it
makes sense to change the show/hide transitions to use that instead
of the existing group, to avoid elements layered on top of the
group being excluded from the transitions.
Windows can sometimes be focused, or appear to be focused, without being
at the exact top of the stack, for example in the case of override-redirect
windows, or with attached modal dialogs. In that case, we should not
try to minimize them (as it creates a loop that makes it impossible to restore
the window)
https://bugzilla.gnome.org/show_bug.cgi?id=694905
Mutter now makes session registration an explicit required
step. This is so we can tell the session manager when
we're ready to move on to the next phase.
This commit calls the new Meta.register_with_session() api after we're
initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
"description" is documented as a valid field for search result metas,
and ListSearchResults implements it, so pass it down to be used.
Also, don't wrap the description in quotes, so that the search provider
can decide if it is an excerpt from the searched text or something else.
And to that extent, set use_markup to true, so that terms can be
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=694906
This can happen if you open two or three terminal windows, and then
open the overview -- they're not centered. The issue is that because
of the WINDOW_CLONE_MAXIMUM_SCALE clamping, the scale that is being
laid out is different from the scale that the layout was calculated
for.
Implement and document a hack-ish solution which simply keeps the
scale for the layout as originally calculated, but centers the
windows inside the cell.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
Multiplication is linear, so we can split this out as a separate
component. This will make it easier to think of it as an additional
per-window scaling factor, rather than tweaking the scale a bit,
which is more correct to the model.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
While we won't tear down the entire strategy infrastructure, we want to
rework some layout code in the future, so just tear this piece out for
now.
https://bugzilla.gnome.org/show_bug.cgi?id=694902
As a special-case to the "cap event" rules, this allows a heavy swipe
from top to bottom to allow triggering the tray without having to push
into it.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
When pressing against the bottom of the screen, we shouldn't
really take more than 15px from each event, to prevent spruious
mouse movements from opening the barrier.
https://bugzilla.gnome.org/show_bug.cgi?id=694467
gnome-settings-daemon will be changed to override the XSetting in
the case where we're on a remote display rather than overwriting a
user setting, so we need to look at the XSetting here.
https://bugzilla.gnome.org/show_bug.cgi?id=694320
Previously, we would create one StBin per monitor, but each was positioned
at 0,0 and sized as the screen, so they would overlap and draw the box shadows
on top of the other backgrounds.
Instead, we need to size appropriately the bin, and then we need to position
the actual MetaBacgroundActor at 0,0, so add a flag to BackgroundManager
for this.
Also, get rid of MetaBackgroundGroup, they do nothing because the screenshield
is not a descendant of the MetaWindowGroup and because the widget in between
blocks the propagation of the visible region. At the same time, use a
widget, not a bin, because StBin requires you to set .child, not call add_child().
https://bugzilla.gnome.org/show_bug.cgi?id=694394
We recently started to trim leading and trailing whitespace from
the search string, and not to trigger a search when the resulting
string was empty. However we still allow whitespace to trigger
type-ahead-find, so that the key focus is moved briefly to the
search entry and back to the stage, resulting in a disruptive
flickering of the entry.
Fix this by excluding whitespace from triggering type-ahead-find.
https://bugzilla.gnome.org/show_bug.cgi?id=694475
xdndHandler used to wait for the stage to show up before calling
global.init_xdnd() . Since commit 65303d027a xdndHandler is initalized
later so the stage might be already visible at this point causing the
show signal never to be emitted and thus global.init_xdnd will never
be called.
Fix that by checking by calling global.init_xdnd without waiting for
the stage's show signal to be emitted, as the stage is guaranted to be
visible at this point.
The key was removed from gsettings-desktop-schemas, GNOME should
always draw a background: the key existed to support xsetroot, but
we no longer read the _XROOTPMAP_ID.
https://bugzilla.gnome.org/show_bug.cgi?id=694463
If the AllView is scrolled, the vertical scrollbar will take away
some horizontal space on one side, resulting in the content ending
up slightly off-center.
Account for this by using overlay-scrollbars instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
The frequent view should not be scrolled, but to work around the
icon grid overflowing, we used a (non-scrolling) scroll view anyway.
Now that IconGrid:fillParent allows us to avoid overflow, we can
remove this hack.
https://bugzilla.gnome.org/show_bug.cgi?id=694256
We sometimes map the stage before we've loaded a background on it
because of a race asynchronously loading the session mode.
This manifests as the startup animating starting over a white
background.
This commit defers showing the stage until after the still frames
are loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
It is useful at times to perform several actions that would usually
close the overview (for instance launching an application) at once.
Currently we allow this by dragging items to a workspace rather than
just clicking it, but it's an odd metaphor with its own set of
problems.
Introduce an alternative approach (inspired by file selection in
file managers) by keeping the overview open if a Control key is
held down.
https://bugzilla.gnome.org/show_bug.cgi?id=686984
When the user clicks on "View Source" or "Web Page" in the "Extensions" tab of
looking glass, the callback _onViewSource() or _onWebPage() is called and they
try to close looking glass: this._lookingGlass.close();
But it does not work and generate the exception "this._lookingGlass is
undefined". This patch fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=693814
animateIn and animateOut should not reset the scale, otherwise
extra animate calls (which are possible because the diff algorithm
in _redisplay is not optimal) cause unneeded movement.
Therefore, create new items hidden, and have the creator call
animateIn or set the scale/opacity properties manually.
adjustIconSize must be changed to always set the icon size temporarily,
otherwise the first time it computes the icon size with 0 scale.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
The DashActor will known to allocate the show apps button only if the
icon size is (temporarily) too big for the containing box, therefore
it should request just that as the minimum size.
This solves a glitch that happened when removing a favorite and at the
same time causing the dash to expand.
https://bugzilla.gnome.org/show_bug.cgi?id=690643
Using the scroll wheel in the window picker should switch workspaces.
As the picker doesn't have a visible boundary though, it makes sense
to accept scroll-event for the entire overview area. Rather than
making the overview's main actor public, expose scroll-events via
a signal.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
Using the scroll wheel to switch workspaces makes sense, but it is
currently only supported on the workspace switcher, as it conflicts
with window zooming in the picker.
As changing workspaces is far more useful than the zoom feature,
remove the latter in order to "free" the scroll wheel for workspace
switching.
https://bugzilla.gnome.org/show_bug.cgi?id=686639
Right now if a user logs out, they are thrown to the login screen
imediately, without even seeing the dialog close.
This commit fades the dialog out before processing the logout.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Opening and closing a modal dialog is not instant. There
is a transition animation involved. When the dialog is
finished opening, it currently emits the "opened" signal.
When it's finished closing, however, it doesn't emit a
"closed" signal. This means, there's not a good way to
know when the dialog finishes closing.
This commit adds the "closed" signal.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
Modal dialogs take an optional timestamp in their close method.
If the timestamp is not passed in, then global.get_current_time()
is used.
Some callers of the close method pass in global.get_current_time()
unnecessarly (since it's the default).
This commit drops the argument for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694296
And reverse menu order in order to avoid it reading "Change Background… Settings"
"System Settings" shouldn't be used because it's not used to mean the control-center in any other place.
https://bugzilla.gnome.org/show_bug.cgi?id=694290
When a swipe scroll completes, we scroll the active workspace into
view. This works fine if the gesture is completed properly by
emitting 'gesture-end', but not when Clutter considers the gesture
cancelled - in that case, the view remains stuck in an intermediate
position. To fix, treat 'gesture-cancel' the same as 'gesture-end'.
https://bugzilla.gnome.org/show_bug.cgi?id=689394
This means that windows will be positioned correctly with respect
to the panel when the shell starts up, and there won't be adjusting
after the session animation zooms in entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Due to a bad rebase causing freezeUpdateCount to never get initialized,
these functions effectively did nothing. Since we're going to go to a
different mechanism for freezing region updates, let's just tear these
out now instead of fixing them before tearing them out.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
PopupMenuManager eats the next release event, which would otherwise close
the menu, so we need to tell dnd that we're handling it, and no drag should
be started, so it can ungrab the pointer and restore state.
https://bugzilla.gnome.org/show_bug.cgi?id=694276
The arrow origin must be in the coordinate space of the box pointer,
but it cannot be calculated when the box pointer is shown, because it's
not allocated yet, so pass the source to the boxpointer and adjust
the arrow at the next paint.
https://bugzilla.gnome.org/show_bug.cgi?id=694264
St.Bin() really only expects one child at a time, and the
BackgroundManager will add two. This can cause assertion
failures when destroying one of the background actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
BackgroundMenu must ensure the actor it attaches to is reactive, and
the layout manager must create a background menu for the first background
too.
https://bugzilla.gnome.org/show_bug.cgi?id=694227
Right now we arrange the window thumbnails in a grid if there are more than two
rows of them. This was originally intended to reduce the amount of noise in the
thumbnail arrangement. It also made sense when the thumbnails were of a similar
size.
Nowadays we reflect the size of windows in the size of the thumbnail. This
leads to huge amounts of space between some windows when they are grid aligned.
Removing the grid alignment would also lead to larger thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=694210
Right now we hide the window group if we're a greeter.
We did this to avoid showing the background. These days
we don't add the background in the first place, so we
can drop this code.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
gnome-desktop's background drawing code supports an
XML format for presenting backgrounds based on time of day,
monitor geometry, etc. Now that we don't use gnome-desktop for drawing the
background, we need to implement that support ourselves to maintain
feature parity.
This commit implements that.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
This commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.
Based on initial work by Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The user widget is the username and avatar shown on
the unlock dialog.
The login dialog has something very similar.
This commit separates the user widget out to its own
file, so we can use it from the login dialog in a
later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now we very abruptly kill the login screen
and start the users session without any transition
out.
This commit introduces a fade out of the dialog and
panels.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
According to the design mockups, the app picker should follow the
recent view pattern as used by applications, where the user is first
offered a subset of applications he/she is likely to start, and only
then allow switching to the full set of installed applications.
So implement the ability to manage several views in AppDisplay and add
FrequentView as additional view, which uses the existing ShellAppUsage
to display a list of frequently used applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
While a group is open, we want to block events on items underneath,
but still allow interaction with components outside the app display
as well as scrolling of the view as a whole.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
App folders are intended for grouping some applications, not to
assign a category to every single application, so we will only
create folders for a selected subset of the existing categories.
Software/Alacarte will eventually allow to create/modify those
folders, so store the setting in GSettings so that it can be
shared with those applications.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
At the moment when loading the applications, each app is inserted
at its correct (alphabetical) position. Avoid this overhead by
loading all apps first, then sort them once and fill the grid with
the sorted actors.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AllView will be updated to allow app folders in addition to app
launchers. Folders will pop up in the existing view, so add an
additional stack widget into the hierarchy which popups will use
as parent.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
We are going to introduce app folders, which will also present an
alphabetical list of applications, but use a different UI. In
preparation for that, split out the item logic into an abstract
base class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
With categories removed, the separation between AllAppDisplay and
ViewByCategories no longer makes sense. Also use this opportunity
to rename the outdated AllAppDisplay to AppDisplay; it will
eventually be used to manage different views.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
AppIcon is just a tiny wrapper around BaseIcon, which does not add
anything over using BaseIcon directly, so merge its code with
AppWellIcon. As the concept of the "app well" has not been used
since well before 3.0, use AppIcon as name for the merged class.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
Doing it before the grab messes up the grab helper's tracking
of where the focus was before, leading to it not tracking the
saved focus correctly, meaning that when we pop the menu back
down with escape, it doesn't restore focus correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=694123
Starting the startup animation when we don't have that much IO
makes it a lot more visible.
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=682429
commit 92083eaf76 made
session mode loading an asynchronous operation.
Aspects of the session mode aren't known immediately at
start up. For instance, sessionMode.isGreeter returns
false for greeter sessions until the asynchronous
operation completes.
This commit defers start up processing until the session
mode is fully known.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The complex overview transition code means that there's no easy
way to handle with this right now. Blocking the message tray
while the overview is animating seems like the correct thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
The activities button may come and go at any moment now that we
have a dynamic panel. We need to re-check the activities button
whenever the panel is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
Making them not fully opaque just makes them harder to see and there is no reason why the user should care whether the window is minimized or not when
switching to a window display them like any other windows.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
Alt-Tab away from a monitor sized on the primary monitor results into the top
panel being displayed on top of the window which looks very bad.
So just hide those windows by minimizing them.
The icon geometry animation does not really make sense for fullscreen windows
so just fade them out.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
All the complexity with a custom actor and a generic container was
just to add some padding below the overview controls. Remove that,
and use CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694100
Since GNOME 3.6, switching XKB layouts changes the group
configuration. This patch tries to track group configuration changes
and reconstruct UI as needed. See also caribou bug#694011.
https://bugzilla.gnome.org/show_bug.cgi?id=681735
Commit 6b4f524620 removed the layer checks
_updateFullscreen ... this causes corruption when alt-tabbing out
of a fullscreen window so restore the check.
The commit also removed the screen sized check so we are no longer
setting all monitors to fullscreen. Fix that as well by using
window.is_screen_sized() to perform the check.
https://bugzilla.gnome.org/show_bug.cgi?id=694079
If the animation time is not the same for these two, the translation
will be adjusted to the allocation during the tween, resulting in a jump
in the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=694035
The top_window_group blocks the panel elements from being found by the XDND
pick so hide the whole group from picks as we never attempt to pick its contents
anyway.
Account for the search entry space at the bottom (the former message
tray clone) individually in each side control, instead of packing
another actor in the overview.
This allows us to extend the central view all the way to the bottom,
while still keeping controls centered vertically.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
Don't show the message tray in the overview by default. From now on the
message tray in overview behaves as regularly, i.e. it will slide up the
overview on Super+M keypress.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
StBoxLayout always fills on the orthogonal direction, so the icon
becomes distorted as the layout grows to accomodate more details.
Instead, use a bin that aligns at the start.
https://bugzilla.gnome.org/show_bug.cgi?id=693822
ScreenShield uses Notification.bannerBodyText to fill the body of detailed
notifications, so use a separate boolean property to indicate it was already
added to the body.
https://bugzilla.gnome.org/show_bug.cgi?id=693822
Calling onUngrab() may change key focus, either directly or
indirectly (e.g. hiding the actor). Such key focus changes
would cause an extra actor to be ungrabbed, so make sure to
ignore such focus changes while we're ungrabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
If we don't this for a nested grabFocus grab, the notify::key-focus
will be called, not think that the new key focus is part of the
grab, and cancel the full grab. This leaves the grab helper in an
inconsistent and confused state, as the grab is pushed onto the
grab stack after.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
While debugging, I found that the signal to focus-window-changed
was never getting disconnected, making a call to ungrab every time
the focus window changed, even if there were no focus grabs anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=693975
When we reset the state of the checked button due to the overview
showing and hiding, block the normal checked callback and immediately
switch to the workspaces page, so that windows seamlessly fade in.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Set the checked property explicitly. This is because
resetShowAppsButton() will only be used to flip the button state
blocking the page change in a future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
And use it in overviewControls. When we moved this code from overview.js
to overviewControls.js we lost a condition so we now slide in controls
even when going back from the overview, which looks bad.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Early on, search was based on a list of terms, which was like a set
of tags, in that terms were OR'd, and that order didn't matter. As
such, modifying any one of the terms wouldn't produce new results.
Nowadays, providers take the order into account, so a substring
should only be the case if new terms are added to the end.
https://bugzilla.gnome.org/show_bug.cgi?id=693935
If WindowOverlay.relayout() is called without animation, we must stop
any preexisting animation, otherwise it will continue to run with the
previous parameters and cause the overlay to end up in the wrong position.
https://bugzilla.gnome.org/show_bug.cgi?id=693970
The slideX property controls the allocation of the view selector; since
we now know when there are no visible views from the page-empty signal,
we can use it to set the full slideX for the next page at that time,
allowing the new view to fade in with the right width.
This allows us to use simple x translations for the side components when
switching pages, keeping the noise due to resizes at the minimum.
The slideX resize for now is kept for DnD, and will always be needed for
the thumbnails box when showing the windows page.
https://bugzilla.gnome.org/show_bug.cgi?id=693924
If we increment our index variable while looping, this means that
firstNewEvent will be one higher than it should. With a length 1
array, all events will be removed, so this has a cascading effect
that events will not be stored at all.
https://bugzilla.gnome.org/show_bug.cgi?id=693854
NMClient recently got more heavyweight, with a property holding supported
connections. As fully initializing a NMObject is a recursive operation
and requires multiple DBus calls, switch to async initalization for NMClient
and NMRemoteSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683288
We want to make Tweener short-circuit animations when resources are
constrained, so this is not going to work.
Instead, use a one-second timeout until the seconds left reach zero.
https://bugzilla.gnome.org/show_bug.cgi?id=655746
After moving the dummy source actor, we still have to poke the
boxpointer so that it gets repositioned.
This has always been broken but went unnoticed until now since none of
the commonly used engines currently depend on this method. Thanks to
Mathieu Bridon for pointing it out.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
setCandidates() has too many arguments and setting the orientation
isn't particularly related with it. It might also be useful to switch
orientation without changing the candidates.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
Make it look more like the mockups.
In order to do that we stop using PopupMenu and friends as it doesn't
really buy us anything and just makes it more cumbersome to add the
style classes we need.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
SlideLayout is a fixed layout that takes care of requesting and
allocating the right sizes so its contents can slide horizontally as the
actor is resized.
Sliding is controlled with a slideX and slideDirection properties, which
do the right thing wrt. RTL automatically.
Also add a SlidingControl base class that will be used by the overview
to pack and slide the workspace thumbnail switcher and the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=682050
This is nothing but a middle man, as the view selector already owns
the search system. We want to start being a bit more tricky with what
we do with the search system so that we ignore whitespace, so let's
cut the middle-man out now.
https://bugzilla.gnome.org/show_bug.cgi?id=693458
Have two branches, one for input region and one for struts. This
makes it easier to skip one of the branches, like in the case where
we want to skip input regions if we have a popup menu visible.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
reparent() defines the new actor stacking order based on the
existing depth of the actor, which is flat out wrong. Simply
remove the actor from its old parent and add the new one in.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
GrabHelper saves the actor that had key focus when taking over the grab
(if any). On ungrab, the key focus is either restored or moved to some
child of the saved actor. The latter is unexpected and causes some odd
behavior, so don't be fancy and only restore the actual focus.
https://bugzilla.gnome.org/show_bug.cgi?id=693570
The notifications spec has two hints for playing a sound, sound-file
and sound-name. We can support them using the existing code that
wraps libcanberra.
https://bugzilla.gnome.org/show_bug.cgi?id=642831
Message tray and on-screen keyboard are now exclusive, so remove
all code that shuffles boxes around to make it possible to show
both at the same time.
https://bugzilla.gnome.org/show_bug.cgi?id=662687
The message tray currently operates in three modes: in the overview,
normal, and while the on-screen keyboard is up. The last case is
particularly odd, and exclusively used for chat-notifications. As
users can still use the Chat application directly on touch-only
devices, the additional mode isn't really justified, so remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=662687
The screenshield was not checking the return value of pushModal(), meaning
that it believed it was fully locked when it was not. Later, calling
popModal() would fail, causing an exception and blocking the unlock.
Now when we fail we include an explanatory message, pointing the user
to the actual cause of the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=689106
The curtain animation looks jerky at its current speed, and more so if
we blank the screen immediately at the end. Make it a little slower and
it becomes more confortable.
https://bugzilla.gnome.org/show_bug.cgi?id=691964
When there are multiple sessions, we may get a polkit dialog in
response to clicking 'Reboot' in the end session dialog. If the
polkit dialog gets canceled or otherwise ends unsuccessfully,
we are left with the lightbox that the end session dialog puts
up when 'Reboot' is clicked. To remove the lightbox and make the
session fully functional again, gnome-session will call Close.
https://bugzilla.gnome.org/show_bug.cgi?id=688915
A pressure barrier is a barrier that activates after the user pushes
against the bottom of the screen in a short time. Implement this using
the new XInput 2.3 features that provide extended information about
pointer barriers, and use it so that pushing against the bottom of
the screen edge brings up the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
As pressure barriers need a signalling mechanism to provide
information about when and where they are hit, an object which
provides a signal is a more appropriate abstraction for a pointer
barrier than a functional ID-based approach. Mutter has gained
pointer barrier wrappers, so use its objects instead of ours.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
If the screen lock is enabled, lock the screen before suspension.
When using systemd, this will cover both explicitly suspending from
the user menu and suspension initiated by g-s-d (lid close, power
button).
https://bugzilla.gnome.org/show_bug.cgi?id=686482
While it is possible to keep track of removed sources by tracking
their summary items' actor:.destroy signal, a dedicated signal
mirroring the existing 'source-added' one is more convenient.
https://bugzilla.gnome.org/show_bug.cgi?id=693220
The panel used to provide an .in-overview class which was removed after
the theme stopped using it. Classic mode should use a different top bar
style in the overview, so bring it back (but use a pseudo class this
time for consistency with MessageTray and ActivitiesButton).
https://bugzilla.gnome.org/show_bug.cgi?id=693218
LTE-only modems need to be treated as GSM/HSPA modems, as they all are 3GPP
modems and they all need the same kind of configuration (APN, user, password,
PIN...).
https://bugzilla.gnome.org/show_bug.cgi?id=688144
ModemManager >= 0.7 comes with a new DBus interface. This patch makes the shell
work with the new interface if the modem is detected as being exposed by the new
ModemManager (based on the device.udi string reported by NM).
https://bugzilla.gnome.org/show_bug.cgi?id=687359.
Gnome session started to track the session's active state a while
ago, so use that instead of our own ConsoleKit/logind abstraction
in LoginManager.
https://bugzilla.gnome.org/show_bug.cgi?id=693161
Now that we have an explicit active-but-not-locked state, we should
use different signals to notify changes. lock-status-changed is
renamed to active-changed, and a new locked-changed is introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=693007
While we handle the case where ibus_bus_get_global_engine() returns
NULL, this case actually generates an exception we have to catch to
avoid some (harmless) console spam.
https://bugzilla.gnome.org/show_bug.cgi?id=692995
In time span between idle and lock the shield should behave like autologin,
but should prevent accidental reactivation (for example when using a touch
screen) by showing the curtain.
https://bugzilla.gnome.org/show_bug.cgi?id=692560
gnome-settings-daemon wants to use ActiveChanged to drive screen
blanking policies.
I also added two big comments that should cover all cases, to clear
up what's happening when the idle timers fire.
https://bugzilla.gnome.org/show_bug.cgi?id=691964
We must remove music notifications before we're destroyed, otherwise
they get destroyed with us.
Also, integrate a review comment I previously forgot.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Some notifications, despite being emitted by shell code, should appear
to be from application or "separable" system components. Do that by
associating them with a notification-daemon policy.
Note that for this to look really good, empathy should rename itself
to Chat.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
The designs says that only music notifications should be shown in full
in the screenshield, the others should be either shown as a summary or
with very light details.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Allow message tray sources to provide a NotificationPolicy object,
that will configure how and if the source is displayed. For notification
daemon sources, this object is hooked to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Use the new Hash.Map class, and store signal connections along with
the source and summaryItem. This allows to remove sources without destroying
them.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
syncSectionTitle looks at device list for the section, to understand if
the section should be visible or not, so obviously it needs to see the
new device.
I wonder when this broke.
https://bugzilla.gnome.org/show_bug.cgi?id=692749
During the box pointer animation, other events can trigger an updateState,
losing the information that the summary is hiding and thus never disconnecting
the signals. Then, this stale connections can cause stacktraces, as they
fire when summaryBoxPointerItem is null.
https://bugzilla.gnome.org/show_bug.cgi?id=692693
Hiding notificationWidget with a telepathy notification causes
unfocused to be emitted, which causes a reentrant updateState.
If another notification is queued, it is shown before the old
one is cleared.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
The two classes have been gaining each other's functionality for a little
while, adding the new code wherever it was more convenient. Rather than
have a clear delineation between "This Manages Shell Chrome" and "This
Manages Shell Layout", I think it's better off if we just accept that
the responsibilities are pretty much the same.
https://bugzilla.gnome.org/show_bug.cgi?id=692677
In the overview, when there is no text in the search entry, this._searchActive
will be set to false. Moving the Clutter.Return code block ensures that
pressing enter in the search field after deleting the characters of a search
will no longer launch the #1 application for the previous search.
https://bugzilla.gnome.org/show_bug.cgi?id=692391
gnome-control-center is planning on removing its own tree in the
future. Since it already installs these applications into
/usr/share/applications, just use this for now.
https://bugzilla.gnome.org/show_bug.cgi?id=692483
The one we had before could make unmaximized windows appear to be bigger
than maximized ones, for a few reasons. Ensure that this doesn't happen
again, and add some comments to explain the whys and needs for twiddling
the individual thumbnail size.
https://bugzilla.gnome.org/show_bug.cgi?id=686944
We clamp the overall layout's scale to WINDOW_CLONE_MAXIMUM_SCALE, but since
we do a bit of tweaking to try and make super small windows a tad larger, it's
theoretically possible that windows may become larger than the proper maximum
scale. Fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=686944
On large displays, we don't want the search results list to expand
across the whole screen; set a maximum width of 1000px.
Unfortunately, since in St max-width only affects size requisition, we
need a little custom layout manager to have it applied to the allocation
too.
https://bugzilla.gnome.org/show_bug.cgi?id=692453
'active' isn't terribly clear about just what is active; also, make it
private, remove an useless extra object state we were saving, and
refactor some messy code.
Based on a patch by Tanner Doshier.
https://bugzilla.gnome.org/show_bug.cgi?id=692454
In a gdm session, we may not know what mouse orientation the user
may be in, so it makes sense to support both the left and right
mouse buttons to activate login or other items.
Additionally, add the behavior to all modal dialog items, even in
a user session, because it's unlikely that the user will right-click
on buttons, and it makes for an easier implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=688748
These were lost when we moved away with StIconType. The idea was that
apps needed to include -symbolic in their action IDs, but apps were
not updated, and it never makes sense to have non symbolic icons there,
so let's restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
This fixes the image and scrollbars peeking through in banner mode,
because StTable wasn't able to allocate them at the restricted height
imposed by CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
We must set the image after calling .update(), because we're passing
clear: true and thus we're removing the image too.
Also, we need to specify an explicit icon size, or St.Icon will use
the default (48px)
https://bugzilla.gnome.org/show_bug.cgi?id=692091
destroy() checks if we are visible to decide whether to destroy the
actor immediately or after a fade out animation. Since actors are
visible by default it would always end up destroying only after the
animation time.
https://bugzilla.gnome.org/show_bug.cgi?id=691963
If nothing references the idle monitor, it can be finalized at GC,
causing it to have no effect. Worse, if the finalization happens at
wrong time, the pointer watcher can be permanently off, disabling the
message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=691976
Switching style on Overview::hiding creates a weird effect, as the noise
texture is shown while the overview is still visibile. Instead, wait for
the tray to be fully hidden, then apply the new style.
As now the switch is invisible, there is no need for the transition
(which introduced the same problem on overview showing)
https://bugzilla.gnome.org/show_bug.cgi?id=689091
Add an style class targetting workspaces located outside the overview,
and use it for extra padding around the window clones. Padding is passed
down and applied inside LayoutStrategy, consolidating code that previously
handled the bottom side only.
https://bugzilla.gnome.org/show_bug.cgi?id=690171
The "flash" effect looks awkward when it fades in and out. Real
camera have an immediate flash of light, which then seems to fade
out as our eyes readjust the rapid change in lighting.
https://bugzilla.gnome.org/show_bug.cgi?id=691875
This is similar to how the dateMenu already allows opening the calendar
application. However, the new entry only appears if GNOME Clocks is
installed, as it is not a core GNOME application.
https://bugzilla.gnome.org/show_bug.cgi?id=644390
NM 0.9.7 is still not released even as a tarball, so fix this to work
with 0.9.6 again for now (although it doesn't do any device name
disambiguation in this case now).
https://bugzilla.gnome.org/show_bug.cgi?id=691720
If the setting is enabled, we record the last activated input source
for the currently focused window and switch to it when focusing back
that window. The Overview is considered a window for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=691414
The current code parses the button-layout setting because MetaButtonLayout
was not usable from introspection. With that fixed, we can switch to
using meta_prefs_get_button_layout().
https://bugzilla.gnome.org/show_bug.cgi?id=689263
Due to limitations and bugs in SpiderMonkey's GC, wrapper objects
for cairo contexts and similar may not get cleaned up immediately
after repainting, leading to leaking memory. Explicitly disposing
of such objects after they're not needed can clean up large portions
of memory for cairo surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=685513
With panel buttons changing dynamically on session mode changes we can
no longer rely on a corner's respective box style-changed signal to
find the nearest button.
Instead, make the panel take care of telling the corners to look for a
new button when buttons are changed.
https://bugzilla.gnome.org/show_bug.cgi?id=690180
Acting on each Show/Hide DBus call immediately may cause a lot of
jittery movement when Alt+Tabbing or even just switching tabs in
e.g. gnome-terminal.
To make the OSK feel sturdier, we wait a bit before actually showing
or hiding it so that we can coalesce tight sequences of Show/Hide
calls. I.e. the last call wins which means that we might end up not
doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=688646
We can't pushModal() when showing the subkeys popup because that will
cause the application to lose focus and thus we get a Hide() call for
the whole OSK.
Instead, capture events on the main OSK actor while the subkeys popup
is shown so that we can both prevent events from reaching the main
keys but also cancel the subkeys if the user clicks away in the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=674955
Since we're breaking API already, take this as an occasion to use a
separate interface for all the screenshot-related methods. The interface
name is org.gnome.Shell.Screenshot.
Internally, move all the related code to screenshot.js.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
Since we also support passing a basename now, clients might be
interested in knowing the path used to save the file.
Add an out argument to the interface for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
If a non-absolute path is passed to the screenshot methods, treat it as
a basename for the output image, and automatically try to save it in
$XDG_PICTURES_DIR, falling back to $HOME if it doesn't exist.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
The screensaver schema has a key that it is meant for locking down
the ability to switch user when the screen is locked, but support
for it was not implemented in the new screenshield.
Fix that by checking the key before creating the button.
https://bugzilla.gnome.org/show_bug.cgi?id=691042
When you click Suspend from the user menu, the following things happen:
- we lock the screen internally by calling Main.screenShield.lock() and waiting
for lock-screen-shown
- logind emits a Lock signal, which causes us to lock again
- gnome-settings-daemon notices PrepareForSleep, and calls org.gnome.ScreenSaver.Lock,
just in case, so we lock once more
This means that, if you're lucky, you can see the curtain fall down multiple times,
as each .lock() call resets the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=690858
It's common to do actor.grab_key_focus() before the actor is mapped
which means that we can't reliably determine where the actor is at
notify::key-focus time and thus might end up showing the keyboard on
the wrong monitor.
This is happening, in particular, with the run dialog. Delaying until
we hit the main loop allows us to know where the actor finally is
before showing the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=685856
Rather than add invalid results to the place where you enter JavaScript
commands when you use the eyedropped, add an inspect() function and add
a fake call to it.
https://bugzilla.gnome.org/show_bug.cgi?id=690726
org.gnome.desktop.screensaver.lock-delay contains the grace period
of the screensaver: if deactivated within that many seconds from the
start of the idle period, the shell should not prompt for a password.
This setting correspond to the "Lock screen after" combo in screen
and privacy panels.
https://bugzilla.gnome.org/show_bug.cgi?id=690766
Use the new meta_window_check_alive() to verify if the application is
responding after the user activates an action from the app menu.
This in particular restores the ability to force quit applications
from the menu, even if the use a custom GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
Calculate an icon based on our current state, not a mess of
signal emissions and callbacks. This is a preliminary basic
cleanup patch in preparation for the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=690539
Instead of faking it by adding a bunch of main icons and secondary
icons to our own box, try and recreate the original button box
with the original icons.
https://bugzilla.gnome.org/show_bug.cgi?id=690589
As we may be flipping the box pointer in response to re-allocation,
like the addition of a new actor to the boxpointer, we can't queue
a re-layout while in a re-layout, so defer.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Depending on the current state of arrowSide, the box allocation may be
wrong; e.g. if the user requested a TOP, but we flipped to a BOTTOM, the
next request would look to the y2 value of the flipped BOTTOM, which is
wrong.
Instead, use the origin, plus the calculated preferred size of the box.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Make sure we re-allocate after we flip sides, to ensure that
padding around the child actor is updated correctly. Additionally,
ensure that we flip after we setPosition, as we won't get re-allocated
auotmatically by just changing the position.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Given that it's modifying state, there's no reason it can't be
using it instead. This makes it easier to use, so we aren't passing
in a bunch of instance variables every time.
https://bugzilla.gnome.org/show_bug.cgi?id=690608
Allow users to smoothly scroll on the volume indicator icon
to adjust the volume. Do this by simply passing the scroll
event to the slider inside the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
After the first time the title was placed, we were setting its width,
thus forcing get_preferred_width() to return that as the minimum and
natural width.
To workaround that, explicitly reset the width to -1, -1, causing
StLabel->get_preferred_width() to be called, which would give us a meaningful
value for minimum and natural width.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
WindowOverlay was at times seeing bogus values reported as WindowClone
sizes. Fix that by storing and passing the value from the authoritative
source, that is, the LayoutStrategy.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
If present, InfiniBand devices show up with the ethernet devices (and
the presence of an InfiniBand connection will cause "Wired" to be
renamed to "Ethernet").
https://bugzilla.gnome.org/show_bug.cgi?id=677150
Both WorkspacesDisplay and ThumbnailsBox need to know when windows have been
restacked. Instead of each tracking changes on their own or trying to call
each other, have the overview keep track and do the calculations, emitting
a signal with the result.
https://bugzilla.gnome.org/show_bug.cgi?id=690175
meta_display_add_keybinding() returns a keybinding action ID for
dynamically registered keybindings which can be used to match a
keycode/mask pair to the action it is bound to.
https://bugzilla.gnome.org/show_bug.cgi?id=682315
Instead of storing them globally and having an hardcoded list of
engines which are allowed to change their indicator symbol when the
InputMode property changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682318
We previously scaled windows to (primary.x, 0), which is wrong if the
primary monitor is not at y == 0. At the same time, change the policy
to pick the hot corner on the monitor the window is on, because that's
closest to where it will appear in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
This makes the method usable in places where the associated window actor
might not have the right size (such as from window manager animations).
Also, make the method public from LayoutManager.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
If we overwrite a map animation (for example because the actor is now destroyed),
we need to complete it first, otherwise it starts off from a random
middle point. This is the same treatment opacity gets for normal windows.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
The thumbnail controls are not a separate actor in the overview group
yet, so we need to ensure a spacing between them and the workspaces
view.
Instead of exporting the overview spacing, just add a temporary style
class to the workspaces-view actor for it. It will be removed in the
future when we change the layout of overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
Adjust the layout of the overview and window thumbnails to make them
bigger. Also, make the background shade darker to compensate for the
increased thumbnail density.
https://bugzilla.gnome.org/show_bug.cgi?id=689876
Recreating icons on every style change -- like hover, can have
disasterous effects. Not only is the quick creation/destruction of
the actors bad, but adding/removing actors at runtime queues many
relayouts, which makes the whole system slower as a lot of unnecessary
reallocations are figured out.
While an optimization was here before, it was broken because it
broke high-contrast themes. Connect explicitly to the texture cache
to know when the icon theme has changed, instead of removing a valuable
optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=672941
The message tray actor also includes notifications themselves. We want
our ghost to be sized as the base part of the tray instead.
Just make sure to use the same style class as the base actor then, as
its height is specified by the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
The new privacy panel offers separate settings for the user name
visibility in lock screen and normal mode. The code to support
either setting is already in place, but we need to make sure to
update the user name on session mode changes to pick up the correct
one.
https://bugzilla.gnome.org/show_bug.cgi?id=690049
This is causing more confusion than anything else these days; the DBus
API is properly documented now and that's what people are expected to
use, the rest are implementation details we're not interested in
exposing.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
These are for all search results except apps (and Wanda).
We also simplify a bit the packing of search results, which removes some
ugly code in navigateFocus() where we needed to call
st_widget_navigate_focus() twice, since the grid icon was composed by
two nested boxes, both focusable.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
Display a '+' icon on the provider icon if there are more results that are
hidden. If the provider icon is clicked, ask the provider to launch itself and
perform a search with the current terms.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
When pressing the overlay key three times, things went like this:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* show(), push a modal
Thus, when the showing is done, and then it activated the hiding,
it popped one modal, but not the other. This patch changes things
to be:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* hide(), no-op
That is, mashing the overlay-key when it's showing will always make
it hide, not mashing an odd number of times.
https://bugzilla.gnome.org/show_bug.cgi?id=688589
BoxPointer's API changed to take a BoxPointer.PopupAnimation
enumeration value, but the code was accidentally replaced with
older code when porting the PopupMenuManager code to GrabHelper.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
"toggle" is used when clicking on the source actor. As we don't
actually have a menu, we don't want to actually take any grabs
through the menu system, so make it a no-op rather than have it
toggle the menu state.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
This is necessary for child popups in menus, e.g. while in a combo box,
clicking outside of the user menu should drop the entire menu, but
clicking on the user menu itself should only drop the combo box.
https://bugzilla.gnome.org/show_bug.cgi?id=689109
I have no idea why we used 'event' rather than 'captured-event' before.
'event' has some really strange quirks that came up when porting PopupMenu
to the GrabHelper
https://bugzilla.gnome.org/show_bug.cgi?id=689109
this._gnomecc is currently unused; we actually need a GAppInfo for this
provider if we want to display an icon next to it (see future commits),
so just turn it into one.
We might move this to an external provider altogether in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
This allows us to fix the shortcomings of the original ActivateResult()
method. In particular:
- allow to pass the search terms to the provider
- allow to pass a user interaction timestamp
https://bugzilla.gnome.org/show_bug.cgi?id=689735
The only case when we're interested in using those parameters nowadays
is for DnD, which is handled in a separate method already.
Since we're not going to support DnD for non-app search results anyway,
drop the params from all the activateResults() calls; this will be
useful later since we're going to add another parameter to it.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
We read the implemented version from the search provider's keyfile, and
then create a RemoteSearchProvider object from the right class
accordingly.
Wire ActivateResult() to the new method (without actually passing the
new parameters along) - an actual implementation will be added in a
future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
Defining a mode that differs significantly from the default one
can get rather cumbersome. For convenience, allow mode definitions
to inherit from an existing mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689308
As currently envisioned, the fallback replacement in 3.8 should be
a separate session at the login screen. As we will use extensions
to implement this mode, we need a way to specify extensions per
session rather than per user, so add a session-mode property for
extensions that should be loaded in addition to the user-defined
ones.
https://bugzilla.gnome.org/show_bug.cgi?id=689305
Currently adding a new session mode requires patching the sources.
As defining custom modes can be desirable in some circumstances
(for instance for administrators of kiosk setups), load additional
modes from JSON files.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
Now that we use the new 'switch-applications' keybinding for the
application-based alt-tab popup, we can use the 'switch-windows'
keybinding for a more traditional switcher.
Based heavily on the alternate-tab extension from Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The Shell's alt-tab popup is application-based, so using the
'switch-windows' keybinding for it never really made sense.
Use the newly added 'switch-applications' keybinding instead.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
If the chosen action is not open, the tray should not be closed, to
let the user further interact with it (for example to mute or remove
more sources)
https://bugzilla.gnome.org/show_bug.cgi?id=689296
This is meant to expose the global.session_mode to applications such
as the gnome-tweak-tool, which would need it to differentiate between
the vanilla GNOME Shell mode and the fallback replacement mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689300
Currently we assume that either the initial sessionMode will have
the overview or none of the pushed modes - starting without the
overview and pushing a mode that adds it fails spectacularly.
However this is exactly what we are going to do when loading external
modes asynchronously - we'll initially use the default mode while
the modes are loading, and switch to the mode passed on the command
line when finished. So make sure that the overview UI gets initialized
properly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
Since commit 0c807bddaf, the run dialog no longer handles Escape
key presses itself but uses the action key mechanism of modal dialogs.
As the latter uses key-release events, our own handling of the Escape
key runs on key-press.
Fix this by bailing out early if anything has pushed a modal in addition
to the overview (like system modals, looking glass, ...).
https://bugzilla.gnome.org/show_bug.cgi?id=688196
Invalid ID errors from that function are normal, because the set
of IDs to acknowledge may not match the set in the connection manager
due to race conditions.
This is also what empathy does.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
MessageTray._tween sets the state variable to the in-progress value,
so it must be sure that at the end of the animation the value will
be the corresponding final and nothing else will happen in between.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
Since the introduction of overlay hover borders, there has a been
a timing disconnection between hiding the border and button, and
this creates noise and reduces the effect of the window+overlay
as a single unit.
Solve that by animating the close button too, so that the two actors
are shown and hidden always at the same time.
Also, consolidate the code to make it clear to future authors that
those two items need to stay coordinated.
https://bugzilla.gnome.org/show_bug.cgi?id=688966
Turns out that tweener has a very complex logic to decide when a new
tween on the same properties overrides completely the old, and unfortunately
what we were doing was not enough in all cases.
Just be explicit, and don't let anything else mess with the state.
https://bugzilla.gnome.org/show_bug.cgi?id=688895
On additional monitors the workspacesView takes up the entire monitor
and in some cases windows in overview can end up hard against the
edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=688133
The panel should change appearance according to the sessionMode,
so add a new panelStyle sessionMode property which allows to
specify a mode specific style class for the panel actors.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
The panel corners overlap the panel in order to hide the underline
used for active buttons where it is supposed to arc downwards
following the roundness of the corner.
Unfortunately this prevents us from using a transparent panel background,
as the overlapped area ends up with the wrong transparency. Work around
this limitation by only overlapping the panel if there is a visible
border.
https://bugzilla.gnome.org/show_bug.cgi?id=684573
Commit c3cab28 removed bits setting the password char that was used to
allow typing the password after a failure but before the first question
for the new attempt came.
Without that code, in complex PAM setups you can end up with a visible
password.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Desktop files can specify if the application should only be shown for
specified desktops with OnlyShowIn and NotShowIn directives options.
If a menu category only contained entries for a different desktop, we
were still creating the category.
We now only add a category button if there is at least one application
to be displayed in this category.
https://bugzilla.gnome.org/show_bug.cgi?id=687970
We need to do a better job of indicating login process. This can
sometimes take a few seconds (particularly if you get your password
wrong): we need to give better feedback of what's going on.
This adds a spinner next to the login button if the authorization takes
some time.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The login dialog had these issues:
- the entry was not really disabled, you could still edit text
- the sensitivity state was not reset on verification failure
- the session list was not disabled
The unlock dialog had these issues:
- "Login as another user..." was not insensitive
- redundant password char setting, overwriting the one given by the
question
The entry insensitive style was also wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The "Sign In" button of the login dialog has its look disabled when the
entry is empty, but it can still be triggered by the Enter key.
This fixes the modal dialog so it does not trigger the action of an
insensitive button, and also means we do not need to connect to the
"activate" signal of the entry anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Make the button layout public for callers to be able to have more
control over like adding custom widgets. Also, the clearButtons and
addButton methods are added as convenience for the most frequent usage.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
Open a modal dialog, try to open the message tray -> no effect, the message
tray is blocked by the dialog.
Close the dialog, try to open the message tray by pointer -> still
no effect, because the old timeout id was not cleared the first time,
so the dwell callback thinks the tray is about to open.
https://bugzilla.gnome.org/show_bug.cgi?id=688750
Windows in the overview should be highlighted when hovered, to indicate
they are an active target.
Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=665310
Setting auto-register to true launches the initial registration, and will
afterwards re-launch the agent registration if NetworkManager gets restarted.
When the component is disabled we'll first disable auto-registration, and only
then request to unregister.
https://bugzilla.gnome.org/show_bug.cgi?id=688379
The top panel and message tray icons were by default a gnome foot and
are replaced by better ones. The applications icon is now using the
symbolic apps icon of the dash, and the windows icon is also improved.
https://bugzilla.gnome.org/show_bug.cgi?id=641303
MessageTray tweens both opacity and y to hide or show _notificationWidget,
but only y when expanding it. This means that an existing tween to hide
the notification will continue running, clearing the notification state.
If the hiding one completes before the showing one, the onComplete handler
will throw an exception (because the notification was nullified) and
therefore break the state tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
Instead of adding search providers to the system as we find them, wait
until we loaded information from all the directories, and then add all
providers at once.
This will be useful when we will sort the providers information
according to the sort order saved in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component. Also, there is a race if it is displayed before the images
are loaded: there is no child yet and thus we get this._frame = NaN
which leads to a crash.
Switch to a play/stop API instead, and add a load event callback to the
TextureCache.load_slice_image to exactly know when we can start using
the images.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
As we now allow the ctrl-alt-tab popup on the lock screen, it should
be possible to navigate back from the top bar, so add the corresponding
elements to the switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
The original condition the property was based on was added to make
the a11y switcher available in the login screen, though it did never
work properly - after popping up the switcher, additional tab key
presses were ignored. As we are now able to filter bindings much more
selectively, we can simplify the check and drop the sessionMode property.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
With the new flexible system in place, there's no point explicitly
hardcoding some built-in keybindings; just use the generic mechanism
for everything.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Currently we hardcode the set of keybindings that are available in the
overview; add a generic mechanism to specify in which KeybindingModes
a keybinding should be available.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
We are currently using a hack to allow a select set of keybindings
in the overview. Implement the new MetaPlugin keybinding_filter
hook, which provides a cleaner way to achieve the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Remove section titles for ethernet and mobile broadband, and replace
them with device status items that recognize if multiple devices are
installed in the same section, and if so automatically disambiguate.
https://bugzilla.gnome.org/show_bug.cgi?id=677142
Due to an oversight, the width of the password entry is currently
determined by the length of the message description. Fix the flags
so that the entry spans the entire width of the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=684810
When updating the dash, we already avoid all animations while the
overview is hidden. However, as we are using Main.queueDeferredWork(),
updates may be deferred up to ~20 seconds while the overview is hidden.
If the overview is entered before a queued update has taken place, it
will be run immediately on map - as the overview is visible by then,
this means animating any outstanding changes.
Work around this by skipping animations during overview transitions as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=686530
If the session mode has no locking support, screenshield had code to
unlock automatically, but it did so by checking the return value of
the constructor, instead of checking if the constructor was actually
callable, so it would get a TypeError before reaching the check.
https://bugzilla.gnome.org/show_bug.cgi?id=687708
At the moment, only the mouse can be used to focus and answer a chat
notification.
This adds a new keybinding (defaults to <Super>+n) to focus and expand
the active notification.
https://bugzilla.gnome.org/show_bug.cgi?id=652082
When in the overview, if you move the mouse cursor over one of the
application launchers in the dash, all the unrelated windows are dimmed
both both in the window view and in the workspace view.
It helps to easily understand whether or not there are already opened
windows for this application, and where they are. It can also help in
differentiating the windows in the overview (sometimes the thumbnails
aren't precise enough to easily know which thumbnail belongs to which
application).
https://bugzilla.gnome.org/show_bug.cgi?id=657315
This has also the benefit of getting the application even if it can not
be retrieved through AppSystem, which can happen if the runtime WMClass
does not match the one of the desktop file.
This especially looked wrong with the following commits related to the
bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
We simply hide the label when the popup is opened instead of relying
on the popup state when the hover state change.
To do this we replace the flag isMenuUp by a 'menu-state-changed' signal
on the AppWellIcon. This simplifies the dash label visibility handling
code that need additional changes for the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
Initializing this synchronously means that we will possibly wait for the
process to be auto-activated and answering to our call.
If the process is already running it also might not answer immediately
our request, as it might be doing sync I/O.
The right thing to do is to initialize the proxy asynchronously; there
are try/catch blocks in place for when the object is not available, or
not properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
This is called in the main thread, which we should never block for
synchronous I/O.
Since the operation we're wrapping is async already, just use
g_file_query_info_async() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
Remote search providers install an auxiliary keyfile to specify
static information, such as the object path/bus name needed to activate
the binary. Such keyfiles also specify the application the providers
pushes results for; currently, we support two formats for application
information
- two fields, "Title" and "Icon" that specify a (translatable) title and
an icon name for display
- one field "DesktopId" that specifies the desktop file name of the
application backing the provider, which obsoletes the previous
Title/Icon syntax
Since all providers in GNOME use DesktopId now, and we need to ensure a
remote search providers is always backed by an application for future
development, this commit drops the support for the older syntax.
https://bugzilla.gnome.org/show_bug.cgi?id=687491
Switch from a ClutterDragAction to a ClutterGestureAction, that gives
us the velocity of mouse motion at each step, and use it to compute the
animation time for completing the hide gesture.
https://bugzilla.gnome.org/show_bug.cgi?id=682537
The background is the same as the normal desktop, so we blur and
desaturate it to clearly show that it's not the normal system state.
To do so, we don't use standard ClutterEffects, to avoid the FBO
indirection. Instead, we take advantage of MetaBackgroundActor support
for GLSL code and paint the shaded background texture directly.
https://bugzilla.gnome.org/show_bug.cgi?id=682536
After some changes, the tooltip label at the dash is not available
until it is visually shown. As this is not anymore a reliable
source of accessible name, we just set the accessible name
with the string used on that label.
https://bugzilla.gnome.org/show_bug.cgi?id=686583
If we lock before the user becomes active again, gnome-session will never
change presence from IDLE, and thus we'll never hide the lightbox.
Instead, install our own idle monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=687020
Entering the overview with the overlay key is done on key release but
exiting the overview on key press, which is inconsistent.
This change makes the overview hidden also on key release.
https://bugzilla.gnome.org/show_bug.cgi?id=683024
Adding a radial gradent to the dimming effect gives more depth to
the background.
Shading is computed in a GLSL fragment shader, and uses distance to
center of the screen to interpolate the darkening value to use.
Based on a patch by Pierre-Eric Pelloux-Prayer <pelloux@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=669798
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component.
Switch to a start/stop API instead. Also, update to the first frame at
startup while we are at it, since this is the expected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
You can't login until something has been entered in the password field.
We should therefore make the login button insensitive until you have
entered some text.
https://bugzilla.gnome.org/show_bug.cgi?id=687112
Notifications that are created in response to direct user actions like
"is ready" or "'foo' has been removed from favorites" should always be
displayed even though the user has marked him/herself busy.
https://bugzilla.gnome.org/show_bug.cgi?id=662900
The barrier was introduced to make the message tray hot corner
usable in multiple monitor setups. With the hot corner gone in
3.6, the pointer barrier doesn't make much sense anymore, so
remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=687457
Instead of keeping track of the old adjustment.upper keep track of the
old adjustment.value that corresponded to the bottom scroll position.
This fixes the integrated chatview not always scrolling to the bottom
by removing the assumption that page_size is constant between updates,
which is not the case as the view is presented in various different ways.
https://bugzilla.gnome.org/show_bug.cgi?id=686571
I've heard quite a bit of feedback from people who want to log out,
even if they are the sole user on their system. It doesn't seem worth
alienating them over this; so add a setting to make the 'Log out' item
always show up.
https://bugzilla.gnome.org/show_bug.cgi?id=686057
While we recreate icons on style changes elsewhere, the faded
icon in the application menu will stick around after icon theme
changes until another application is focused.
https://bugzilla.gnome.org/show_bug.cgi?id=687224
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
