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
Otherwise the second attempt tot login after pressing "escape" key
on the login "freeze" and raise an exception about IOError operation
cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=681537
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
