Both the screen shield and the notification section in the message
list create their own UI for notifications rather than using the
notification actor itself. Currently there is no clean way for such
representations to include notification actions - we will need this
as we will soon use a separate actor for banners as well, so keep
track of actions added via addAction().
Notifications in the message list cannot be expanded, however we will
soon use NotificationMessage to re-implement notification banners, where
we still want actions and expanded content.
While this functionality logically belongs to the future banner subclass,
it is cleaner and easier to have the basic support in the base class.
This also leaves the door open for expanded notifications in the summary,
should that become a thing again.
The panel is not visible when in fullscreen, but critical notifications
may still be shown - having them pop out from where the panel would be
looks unpolished, so adjust the trayBox accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was removed as actors that should not affect the input
region can simply be added to the uiGroup instead. However
the property is useful to add non-reactive chrome, but then
use trackChrome() to add a child to the input region.
This reverts commit e62d22a50e.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Occasionally it makes sense to constrain to a monitor's work-area
rather than the entire monitor, so implement that behavior and add
a property to turn it on.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
St's hover tracking uses ClutterInputDevice, which unfortunately may use
an outdated cursor position to determine which actor is hovered. Using
MetaCursorTracker instead would fix this, but would require linking St with
libmutter - avoid this for now by manually fixing up Clutter's view of
the pointer position in the case where we rely on it working properly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
While applications can no longer spam the users with a constant stream
of banner notifications, it is still possible to drown the summary in
the message list. Avoid this by limiting the number of notifications a
single source is allowed to display simultaniously.
test-xy-stress in libnotify's tests suddenly became fun again ...
https://bugzilla.gnome.org/show_bug.cgi?id=744850
We want to shield users from being overloaded by an overwhelming stream
of notification banners, either due to coming back from idle/lock or
because an application is misbehaving. Previously we replaced all queued
notifications with a summary notification in that case, but now that
notifications appear in the summary immediately, we can simply stop
adding them to the queue and rely on the date menu to convey that
information to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The summary may contain notifications that have not been seen by the user
and won't be shown as banner. Currently this is only the case for resident
notifications that are emitted by the focused app, but it will become more
common as we will start limiting the number of queued notifications.
Indicate to the user that more notifications are available by displaying a
small dot in the top bar button.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Source::count-updated is emitted as notifications are added or removed,
which is correct for the primary notification count. However it is not
for the unseen count, which will also change when a notification is
acknowledged without being removed. At the moment this does not matter,
as the unseen count is only used on the screen shield and notifications
are never acknowledged while the screen is locked. However we will soon
use the unseen count in the normal session as well, so emit the signal
in this case too.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Using a "There are too many notifications" notification is a bit odd,
and we will address the issue differently soon. So rather than update
the notification to do something else than opening the mostly empty and
useless tray when clicked, remove it altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
No Source subclass used it to do anything special, and with sources
no longer having any UI representation on their own, doing anything
else isn't useful either, so just kill off that hook.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was a nice feature, but with sources no longer being represented in
the UI, there is no longer a way for users to make use of it. If we want
to bring the feature back in the future, it would probably make more
sense to implement via the chat source's policy anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The notification list in the calendar drop-down now functions as summary
area, so we can drop it from the message tray and remove a lot of complexity
from the state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
There is not good reason why activating a GTK+ notification should
behave fundamentally different from fd.o notifications - we don't
raise the app because we expect it to perform an appropriate action,
but that does not include closing overview or calendar for us ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Just like we leave the overview when activating a notification,
the calendar popup should be closed - after all, the only case
where the calendar is open when a notification's default action
is activated is the user clicking an entry in the message list's
notification section.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Since notification support was added to the lock screen, notifications
are no longer necessarily represented by the actual notification actor
anymore. However when an existing notification is updated, external
representations currently become outdated.
Emit an appropriate signal which allows them to update.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
As the popup's height depends on its content, which itself varies
depending on the selected day, browsing the calendar can result
in distracting size changes. To avoid this, the design calls for
the height to be frozen to the previous one in that case.
As the popup will always open with the current day selected, we
don't have to be very sophisticated and can just lock the popup
to the height corresponding to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is not only a replacement for the calendar events
list, it will also take over the notification summary from the
message tray. As we start drawing events from other sources than
calendars, hiding it based on whether or not any calendars have
been set up is no longer appropriate, so always include it in the
calendar drop-down now.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is a scrollable list that will hold sections of
different types of time-related messages like notifications,
calendar events or birthday reminders. When no section displays
any content for the selected date, a placeholder is shown instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will start using both URLHighlighter and the _fixMarkup() helper
method the same way it's used in MessageTray. Usually we should
make fixMarkup() public and call the existing methods, but we are
planning for them to go away soon, so just keep two copies until
the original one is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
We will soon replace regular menu items in the calendar drop-down
with more complex elements.
However there will still be items that should close the drop down
when activated - rather than making the menu available throughout
the hierarchy (and eventually from outside as well when we add the
notifications list), have a public method on a global object just
like the ubiquitous Main.overview.hide().
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Menu items are on their way out of the calendar drop down, so let's
start with the easy one. This one is removed without replacement,
but then the Date & Time panel should be a one-time stop for most
users anyway, so not having a direct shortcut should not be much of
a problem. It is also the last remaining Settings item outside the
system menu ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The new design has the events list on the left and the calendar on the
right, so swap them around and remove the vertical separator between
them in favor of some additional whitespace as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
So we can style it differently than :hover.
We already have a active state for the menu items which includes
more than hover. For example, when the keyboard focus moves to a item
or we select programatically a item.
For this reason we need a style class named active for the meaning we
give to it in menu items, and a pseudo class active with the meaning
CSS has.
https://bugzilla.gnome.org/show_bug.cgi?id=744680
Don't assume struts are on the primary monitor while computing
the strut side. Instead, find the first monitor that overlaps the
strut and compute the strut side using it.
https://bugzilla.gnome.org/show_bug.cgi?id=744183
This capability was only really useful for media players, and with
music notifications no longer being special, we can simplify a bit
by removing support for it.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Music is no longer a special type of notification according
to the design. If we want to resurrect the functionality, we
can reimplement it with a dedicated API like MPRIS rather
than piggy-bagging on the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
According to the design, hotplug notifications should no longer offer
an eject action and use regular notification buttons (but using icon
and text), the default action when clicking the notification itself
is to launch the file browser.
Also as the corresponding resident notification is gone, it no
longer makes sense to make the notification transient.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
The new notification system will no longer give access to actions
from the notifications list, so a notification that is never
displayed as banner does not make sense here.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Tray icons make for a terrible UI on their own, but trying to
shoehorn them into the notification system has only made them
worse. At least for the time being this removal is temporary
and support for tray icons will be back, but no longer as part
of the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Users currently can't switch VTs while at the login screen.
This commit fixes that, by adding the relevant keybindings
to the login screen's allowed keybindings list.
https://bugzilla.gnome.org/show_bug.cgi?id=744800
drawing cursor is on by default, so the code:
if (options['draw-cursor'])
recorder.set_draw_cursor(options['draw-cursor']);
never lets you unset it.
Fix is to use 'draw-cursor' in options instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744599
When opening a panel menu, we set it's max-height to the available
work-area height to keep menus with scrollable content from growing
outside the monitor. However a menu that extends all the way down
to the bottom edge does not look great either, so also take margins
into account here.
https://bugzilla.gnome.org/show_bug.cgi?id=744498
Ouch, classy - we are telling translators to use a '24h' time
format for the '12h' time format string.
Luckily, only a handful of translations actually followed the
comment (de,hu,id,is,kk,nb,nl), and most of the corresponding
locales do not support 12-hour format anyway (only is_IS, at
least on Fedora).
We assume that applications that export a 'new-window' action can open
a new window, so we add an appropriate entry to the context menu.
However this duplicates functionality if the application already
exposes the action via the desktop file - don't add our own entry
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=744446
This DBus API is intended to be used by gnome-control-center's
displays panel to show monitor labels.
Each output (i.e. hardware monitor) identified by its
org.gnome.Mutter.DisplayConfig API ID has at most one label. On
mirrored setups, all the labels for outputs corresponding to the same
logical monitor (i.e. showing the same contents in the same mode) are
shown together.
At most, only one DBus client at a time is allowed to show labels.
https://bugzilla.gnome.org/show_bug.cgi?id=743744
Because there's nothing (in single-monitor setups) that could
take the drop in this case.
* js/ui/appDisplay.js:
AllView._loadApps(), FrequentView._loadApps(): Pass
an isDraggable parameter when creating the AppIcons,
depending on whether the favorite-apps key is locked.
AppIcon._init(): Check for isDraggable in the params and
do not create _draggable if it was specified, to prevent a
drag from starting.
AppIcon.popupMenu(): Check _draggable before trying to call
fakeRelease on it.
* js/ui/dash.js: Dash._createAppItem(): Check AppIcon._draggable
before trying to connect to its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
In a lockdown scenario, where the favorite-apps GSettings key is not
writable, hide the menu items for adding and removing favorites from the
dash menu. Additionally, reject drops to the dash for DND.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
After the login banner is shown and hidden, the first user
in the user list becomes non-reactive. This is because the
banner is given an opacity of 0, but still allocated.
This commit fixes that by hiding the banner explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=743370
Normally when a user uses the login screen to log in, the
login screen gets killed and the user session takes over
the display.
This doesn't happen for wayland sessions, though. Instead,
the login screen gets reset, and the wayland session is started
on another VT.
The greeter proxy object needs to be recreated after this reset,
since it's associated with state no longer coupled to the login
screen after the reset.
This commit moves greeter proxy creation to happen at reset time.
https://bugzilla.gnome.org/show_bug.cgi?id=743371
The code described by the comment was moved away in commit eda27d51,
so it is not misleading at best. It wasn't too useful to begin with,
so kill it off rather than moving it to the correct place ...
When using dynamic workspaces, a new workspace will be appended
when moving a window down to the last (empty) workspace. It makes
sense to extend the behavior in the opposite direction, and prepend
a new workspace when moving a window up from the first workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
New workspaces are inserted by shifting all windows on workspaces
below the insertion position down. As a result, when the new
workspace is inserted before the active one, we end up with
the illusion of a workspace switch. Instead, activate the workspace
on which the windows from the active one ended up.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
We are not supposed to mess around with OR windows, so don't try
to shift them to a different workspace. This fixes a warning with
newer versions of mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
We will soon allow to insert a new workspace by other means than
DND in between workspace thumbnails, so move the relevant code
to a new windowManager method.
https://bugzilla.gnome.org/show_bug.cgi?id=665764
Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
We check for (metasNeeded.length == 0) at the beginning of the function,
which is only ever called when when a non-zero number of results is
received back from the provider. Effectively, this means that
(metas.length != metasNeeded.length) will also catch (metas.length == 0)
and print a nicer message to the log.
The updateSearch() function is called in SearchResults every time new
search hits are available from a search provider; SearchResults will
wait for updateSearch() to complete in a callaback, to update the
overall progress of the search operation.
updateSearch() will call _ensureResultActors(), which will in turn call
getResultMetas() on the search provider, which is an operation that can
fail arbitrarily or return inconsistent data, as it's entirely in the
hands of the search provider.
In case _ensureResultActors() returns a failure, updateSearch() is
currently failing to notify the passed-in callback, which might leave
SearchResults in an inconsistent state: make sure the asynchronous flow
always ends up with a notification to the updateSearch() callback.
So that we'll recreate it the next time we want to show it. Otherwise,
we'll try to call things on a half-destroyed ResizePopup and end up
causing errors instead of showing the user their resize popup.
This will allow g-s-d to handle actions differently based on the
current mode - namely, allow the power button when locked, but
make sure to never show any dialogs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
Adding new parameters to the signal currently will break keybindings
until gnome-settings-daemon is updated to the new API as well.
Put additional parameters into a dictionary instead to make future
extensions easier.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
When animating workspace switches, windows on the old and new workspaces
are temporarily reparented. If windows are restacked, those windows will
thus be ignored by mutter until meta_switch_workspace_completed() resyncs
the stacking at the end of the animation.
As a result, activating a window on another workspace that is not on top
of the stack is very noticeably a two-step operation of switching workspace
and raising the window. There is a technical reason for that order[0], but
we can avoid the visible disruption by manually syncing the stack during
the switch operation.
[0] https://git.gnome.org/browse/mutter/tree/src/core/workspace.c#n590https://bugzilla.gnome.org/show_bug.cgi?id=741680
Just like keybindings and the message tray pointer barrier, gestures
don't always make sense - for instance, swiping up the screen shield
should not trigger the message tray just as the SelectArea action around
the left edge should not open the overview.
To avoid this, restrict gestures based on the current keybinding mode.
https://bugzilla.gnome.org/show_bug.cgi?id=740237
Frequently banner messages are longer than can reasonable
fit in a one column view, which leads to a smooshed layout.
This commit changes the layout to a two column view, with the
banner on the left and the prompt on the right, if the banner
message is long enough that it can't fit well above the prompt.
If there isn't enough space for two columns then we keep the
one column layout but add scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.
This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.
This commit moves the banner message to display when the user is
prompted for login credentials instead of when showing the user
list. It also adds a scrollbar if the message is too long.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
The login screen is pretty custom full screen container and the standard
layout managers aren't really a good fit for the kind of layout that's
happening. This will be even more problematic with upcoming changes
to login banners, so we need to switch techniques.
This commit moves login dialog over to using a custom allocate handler
that has specific domain knowledge of the parts of the login screen
and where they go.
https://bugzilla.gnome.org/show_bug.cgi?id=703972
In certain cases the timeout for starting the calendar helper can
be reached but the calendar helper still loads fine. If so, just
ignore the timeout and wait until we get a notification from
dbus of the successful start.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
While the default Shell style is fairly decent with regard to
accessibility requirements, having the ability to tweak certain
aspects where the regular style works less well is still useful.
For this purpose, try to load a -high-contrast theme variant of
the default stylesheet when a high-contrast theme is requested
(as determined by the GTK+ theme name).
https://bugzilla.gnome.org/show_bug.cgi?id=740447
_hideDone checks _shown to determine if anything has shown the overview
while we hid it, and if so, shows the overview forward just in case.
In a local patch that called _hideDone immediately inside _hide for
testing, this broke. While we don't actually depend on this anywhere,
it doesn't hurt so that the next person to hack this up (perhaps me!)
doesn't get stuck debugging it for 20 minutes.
Since moving to a GFile based API in commit 642bf2b778,
setThemeStylesheet() no longer accepts %null to revert to
the default theme. We should have some way to revert to the
default and the least intrusive option is to return to the
old behavior, so do that.
Correctly computing the ISO week number is tricky and we already
have code in the platform to do it, so just refer its computation
to GDateTime rather than doing it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=736722
Using a separate property to show when the application is busy rather
than cramming it into the state property makes the code clearer. In most
places we only care if an app is running or not, not whether it is
actually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
If the user list is disabled and the user clicks cancel quickly enough
after typing their username, they can get in a state where the
auth prompt gets stuck in the insensitive state.
This is because the login dialog code makes the prompt insensitive
while while pam is processing the provided username, but the prompt
only makes itself sensitive again when it is hidden.
This commit makes it sensitive right before asking for a username again.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Once verification has succeeded, the train's already
left the building and we shouldn't allow canceling.
This commit renders the cancel button non-reactive
and makes the cancel function be a noop after
verification succeeds.
https://bugzilla.gnome.org/show_bug.cgi?id=740141
Due to a typo we were always removing the first (index 0) connection
from the global list of connections instead of the correct one.
This resulted in some connections remaining in the shell's connection
list long after they were removed. In particular, this resulted in
multiple copies of a bluetooth connection appearing after suspend/resume
(when the device was readded and the cached connection list was
rescanned).
https://bugzilla.gnome.org/show_bug.cgi?id=740227
I was going to add another DBus property to signal when the shell was
done loading and was idle, and while implementing that I noticed we
aren't emitting PropertyChanged for, well, any property. Let's fix
OverviewActive.
It's unfortunate it's so tedious to correctly implement a DBus
property =/
https://bugzilla.gnome.org/show_bug.cgi?id=704163
Currently, shellDBus only uses the passed in monitor index if it's
strictly > 0. A zero-index monitor is a valid one though, so don't
restrict this to strictly positive indices.
https://bugzilla.gnome.org/show_bug.cgi?id=740074
Commit 1291bcd0c8 implemented it for dateMenu, but the function
is already used in screenShield as well. Just add it globally as
we do for other standard gettext "macros".
Normally users switch xkb input sources and ibus input sources.
But currently the first input source only is running. It's also good
to preload all ibus engines in the logging session so that users switch
input sources quickly without the launching time of input sources.
The following is the ibus change:
https://github.com/ibus/ibus/commit/cff35929a9https://bugzilla.gnome.org/show_bug.cgi?id=695428
WorkspacesDisplay relies on being hidden to disable workspace switches
by scrolling or panning. Usually viewSelector will hide the previous
page on page switch, but we currently miss the case when opening the
overview at the app picker, where the workspaces page is still shown
for the transition, but never hidden.
Fix this by calling hide() in addition to setting the opacity to 0 at
the end of the overview animation.
https://bugzilla.gnome.org/show_bug.cgi?id=737534
Calling g_dbus_proxy_new without any flag means that the caribou
daemon will be launched through D-Bus activation, when creating
a proxy. It smoked out some corner cases in caribou and at-spi2-core,
but generally it would be good to avoid creating unused process.
This patch delays the invocation until the "Run" method is called.
https://bugzilla.gnome.org/show_bug.cgi?id=739712
Leading zeros are common in the 24h format, and indeed used in the
wallclock in the top bar. Convention and consistency within the
same clock format trumps inconsistency between different time formats,
so reverting commit 316f825b2a.
https://bugzilla.gnome.org/show_bug.cgi?id=658675
Splits instantiation of the event source into a separate method,
allowing extensions to subclass the DateMenuButton and provide its
own calendar source.
https://bugzilla.gnome.org/show_bug.cgi?id=672500
There is currently no simple way to inject into AppIcon's state change,
so an extension that wants to do this has to destroy/remove/update all
icons in the Shell (i.e. in the Dash, AllView, FrequentView) on enable()
and disable() after updating AppIcon.prototype._onStateChange, or the
extension must require a restart of the Shell.
To solve this issue, we rename _onStateChanged to _updateRunningStyle,
and connect the notify::state signal with an anonymous function that
calls _updateRunningStyle.
This extra function call should allow extensions to just extend the
updateRunningStyle function in the prototype.
https://bugzilla.gnome.org/show_bug.cgi?id=739497
This patch inlines the function _ellipsizeEventTime into its only caller
_addEvent. This also removes the need for the global const
EventEllipses and is thus removed by this commit as well.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
With commit dc6a60dde, the calendar displays the ending day and time of
a continuing multi-day event on its ending day. This results in the list
not appearing to be sorted. This patch sorts the list according to the
displayed day/time.
With the two appointments
Thursday 0800-1000 Foo, and Wednesday 0900-Friday 1200 Bar and today
being Monday, the rest of the week list currently displays:
F ...1200 Bar
T 0800 Foo
With this patch, the displaying order is switched because Friday comes
after Thursday.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
Currently, multi-day events are shown as individual appointments on each
day. This patch ellipsizes multi-day events to indicate continuation on
the prior or following day (or other time-period.)
The time label spot is now replaced by a box layout that contains the
prefix ellipsis label, the time label and the postfix ellipsis label.
In order to keep the alignment, ellipses are merely invisible (zero
opacity) when hidden.
The ellipses are styled using the events-day-time-ellipses class which,
by default, take the color of the event text.
When RTL is used, the box contents are adjusted accordingly (clutter
does that for us).
An event spanning three days now displays "...All Day..." in the
calendar on the second day.
https://bugzilla.gnome.org/show_bug.cgi?id=727302
It is really annoying for the user to acknowledge multiple notifications
when they queue up. So, to prevent a notification flood that has to be
handled by the user one-by-one, a summarized-notification feature is
added which leaves a single summarized-notification for the user,
replacing multiple notifications if the number exceeds 1, which they may
or may not acknowledge. When this summarized-notification is acknowledged,
the message-tray is opened where they can view the notifications that were
summarized. This helps the user concentrate on his primary task
simultaneously informing them about the new notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=702460
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
Since the background rework, SystemBackground is no longer a transparent
actor that you have to stack on top of a solid background, it is an
opaque actor. Fix the color of the background actor, and remove places
where we were setting the background color underneath the system background
and expecting blending - in particular, we can always set no_clear_hint
on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=738652
When monitors change, the previous index might not mean the same
physical monitor anymore, in fact, it might become invalid. In the
latter case, we'll actually get a JS error when accessing
this.keyboardMonitor in _updateKeyboardBox() . To avoid this, let's
just always reset the OSK to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=738536
Incorrect braces meant that if the ShellUserVerifier was destroyed before
the call to fprintManager.GetDefaultDeviceRemote(), the reply would result in
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=738256
Most of the code handles the sources setting being empty and
InputSourceManager.currentSource being null because previously the
"model" (i.e. the sources list) was kept in gnome-settings-daemon.
But this is fragile and since we're now the canonical place where the
list lives we can force it to never be empty even if the gsetting is
empty or contains only invalid entries. Adding the default keyboard
layout in that case is the safest thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=738303
Commit a4475465f1 fixed the wrong alignment for the fully visible
control, but regressed the partially slid-out one; take the slideX
factor into account to get the right offset for both cases.
Controls that slide left are located on the left, so the offset to
align them with the corresponding edge is always 0. It's controls
on the right that need a different offset when the available width
exceeds the child's width.
https://bugzilla.gnome.org/show_bug.cgi?id=728899
Currently we use the same amount of total delay divided by all items,
but that makes the items animate slow if the amount of items is small.
To avoid that, use a smaller total amount delay for an amount of items
smaller than four.
https://bugzilla.gnome.org/show_bug.cgi?id=737017
This commit ensures the login screen gets focused after
the screen shield is raised.
The code affects the unlock screen as well, but it's
less important since the unlock screen gets destroyed
and recreated each time the curtain moves, so it
has an opportunity to take focus on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=708105
We currently allow infinite number of screenshot requests to be active at
the same time, which can "dos" the system and cause OOM.
So fail subsequent requests for the same sender when a screenshot operation
is already running.
https://bugzilla.gnome.org/show_bug.cgi?id=737456
We currently just clear out the map of recorders (which results
in the top bar indicator to be hidden), but don't stop the actual
recordings.
Spotted by Adel Gadllah on IRC.
Instead of waking up the JS every second to set the clock and update a
date label the user will rarely see, simply use property binding to
bypass JS string handling, and update the date in the menu when the menu
is opened.
Checks for a duplicate search before setting the current search
to true and before cancelling the current search. This ensures that
if a duplicate search occurs while the previous search is still active,
the duplicate search will not incorrectly cancel or change the state
of the previous search.
Indicate to NetworkManager that the Shell's agent supports VPN
hints, and pass those hints to VPN auth dialogs that also indicate
that they support hints.
VPN plugins can request new secrets, for example if the previous
ones are incorrect (eg, user mis-typed the password) or some other
reason (next token code required to re-sync a hardware token).
The specific secret that the VPN wants, and a VPN-specific message,
are passed in hints from the plugin, to NetworkManager, to the
agent (GNOME Shell) and then to the auth dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=737592
If we have a modal, the stage's input region doesn't really matter --
all events go to us anyway. To avoid doing extra work doing animations
when we have a modal, like menus, the overview, and the message tray,
just fizzle out all updates.
To make sure we catch updates, update the input region whenever we end a
modal.
https://bugzilla.gnome.org/show_bug.cgi?id=737001
When the overview is created, search is populated with one actor for
each provider. As they're not hidden though, they will contribute to the
overall size request of the search page, which will shift upwards the
overview grid.
Reviewed-By: Jasper St. Pierre <jstpierre@mecheye.net>
Since (mutter) commit 49400657caae27 we disable the "Always on Top"
action for maximized windows, however when commit e7af257814
moved the window menu into the shell, this behavior was accidentally
extended to partially maximized (including tiled) windows.
As it can be desirable in this case to keep the window visible while
interacting with a different one, restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737382
MetaBackgroundCache doesn't itself use file watches, so when a image
that we are monitoring changes we need to purge it from the cache,
so that when we load it again we get the new image.
https://bugzilla.gnome.org/show_bug.cgi?id=710756
When the keyboard is destroyed, we destroy the keyboard actor, but the
keyboard's menu isn't part of the key itself, so it's never tracked.
The menus are actually tracked actors, so they slow down the layout
manager's code to rebuild regions and other things. Keeping this list
small is a good idea.
To prevent leaking menus, destroy the menu when the key is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=736999
The spring animation has to use clones to escape any clip set on the
parent, as it mainly occurs outside the parent. The same does not apply
to the pulse animation, which is very much in place - in fact, if the
parent is clipped (for instance a scrolled app folder), not having the
clip applied to the animated icons is indeed wrong.
Just animate the original grid actors instead, which gives the expected
result.
https://bugzilla.gnome.org/show_bug.cgi?id=736885
Trying to open an empty folder currently leaves the parent view in a
rather confused state. While we should look into fixing this in the
future, empty folders are not useful at all to begin with, so hide them.
https://bugzilla.gnome.org/show_bug.cgi?id=736910
The summary container will trap the focus if any sources are present,
making the message tray menu unreachable by keynav. Apply the same
hack as in searchDisplay and add a focusTrap to move the focus manually
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=707799
Can't wait to double the size of this list when these start using D-Bus
activation.
These were actually renamed in GNOME 3.12, but we couldn't do anything
about it before, and now we can.
It was assumed that BackgroundSource objects were always destroyed
on monitor changes because the BackgroundManager objects that hold
references were destroyed, but sequencing of updating of different
BackgroundManager objects meant that was not the case.
Properly update any cached Background objects held by the
BackgroundSource on a change to the monitor layout; in particular this
means updating animations in case they are multi-resolution.
All other submenus link to the corresponding settings, so we should
do the same for location - the privacy panel in this case, which now
sports a "Location Services" switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=736542
This lets us considerably clean up the event flow here and change how
things are structured. It also makes sure that we never show "No
Results" -- search.js not being aware of the timeout means that it might
not think that any work was being done when we show the page.
Keep a flag depending on whether a provider is in-flight, and use that
to determine what status label to show.
This ensures that we only show "No Results" when we're done searching
and we're sure that all providers have returned results back to us.
The complexities of tracking these two things separately, with the
display on one half, and the searching on the other half, is difficult
to manage. Squash it all together.
It is quite weird to have those calls/signals using WindowClone as an
argument, it is neater to pass MetaWindows around, and have each user
deal with their own representations of these.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
And use it to lookup the local WindowClone that applies. Otherwise,
WorkspaceThumbnail.WindowClone objects may be mistakenly set, which
are not usable interchangeably with Workspace.WindowClone ones. This
may lead to several misbehaviors as fields available in the second
object but not in the first one are accessed, some those undefined
values get used in math ops, which result in NaNs over the place.
Likewise, the similar functions in WorkspacesViewBase subclasses take
now MetaWindow arguments too.
https://bugzilla.gnome.org/show_bug.cgi?id=735972
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
gnome-settings-daemon doesn't this for us anymore. Note that
ibus-daemon isn't DBus activatable but just spawning it is fine
because it does its own single instance management. The library
notifies us when it shows up and goes away through the connected and
disconnected signals.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
We don't really need this step as a separate method since all
implementations are supposed to be created and shown immediately. This
also ensures that we have items to show in all subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=735976
The enums values of geoclue have gaps in them (so more levels could be
added in future) but enum values of settings don't have such gaps so we
gotta translate between them.
Since desrt says that enums as integers in gsettings are bad, we now
treat accuracy level settings as string.
This fixes the recent regression of geoclue only allowing geiop level
accuracy to apps.
https://bugzilla.gnome.org/show_bug.cgi?id=736479
Since commit e04e507659, we will already get the right icon for the
submenu arrow, so we must not mirror it again. However we do need to
take the text direction into account for the rotation now (but that's
not actually too bad - the resulting code gets quite a bit easier).
https://bugzilla.gnome.org/show_bug.cgi?id=736343
Trust the heuristics in shell_app_can_open_new_window() to get it right
more often than not, and add an appropriate check in activate(). This
makes the behavior consistent with the dash, e.g. we will try to open
a new window (and show the corresponding animation) for apps that don't
have a "New window" item in their dash context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=736329
Commit 9e5704b introduced a regression due to a sloppy mistake not
making actors reactive on animation out.
Fix that making actors reactive when animating out as well.
Our current UI is horrible in dealing with outdated extensions - we
don't give users any indication at all that something is not working as
expected (unless hiding the prefs button as we did until the last commit
counts).
To fix this, make the enable switch insensitive to indicate OutOfDate
extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
It is confusing to treat outdated extensions as if they didn't exist
in some places, but like any other extensions elsewhere. In particular
gnome-tweak-tool still allows to launch prefs for them while making
it clear to users that the extension will not work - opening the
list of installed extensions in that case is unexpected and confusing.
Just remove the version check for now, we will soon follow tweak-tool
and use it to disable the extension switch instead.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
The current code only works for enabled extensions, which means
that extensions that were marked OUT_OF_DATE cannot be enabled
without a restart when disabling the version check.
Fix this by reloading all extensions while making sure to only
enable any extensions when we're supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=736185
Currently we consider the last item animating being the last actor of
the list, but that's wrong since the last item animating depends on the
distance between the source actor and the original position of the
animated actor.
Take that into account to check the last item of the animation.
The code that cleaned up when a background actor was destroyed tried to access
the Background as backgroundActor.background._delegate but when the destroy
signal is emitted, the MetaBackgroundActor was already disposed and
backgroundActor.background NULL.
The rewrite of Mutter's background code (see bug 735637) requires
corresponding changes here - we no longer need to layer multiple
MetaBackgroundActors together.
The general strategy is that a BackgroundSource object is created
per GSettings schema, and keeps either one Background/MetaBackground pair,
or, for animation, a Background/Metabackground pair for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=735638
When you open or close a PopupSubMenu the arrow icon rotates, but
the code previously assumed that the starting angle was a multiple
of 90. If you click the submenu fast enough the rotation could overlap
with the previous rotation and you'd get something that wasn't a multiple
of 90.
Now we ensure that the ending arrowRotation angle is always a multiple
of 90 regardless of what the starting angle is.
https://bugzilla.gnome.org/show_bug.cgi?id=728927
Although the actor are with opacity 0, they were reactive, so the if the
user quickly make a click on the grid while animating it can launch an
app accidentally.
To avoid that make the actors non reactive while animating.
Show the on-screen keyboard if gnome-settings-daemon requests that it
should be shown, such as when using a touchscreen input device. Do this
in addition to monitoring the accessibility setting for the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=702015
Commit 12845f0eef reset translationX to 0 to fix the slide-in
animation of the dash when dragging a search result, but 0 is the
wrong value for the thumbnail slider - the next time it will be
shown, it will just pop up instead of sliding in due to translationX
already being at its target value.
Fix this by making _updateTranslation take the actual visibility into
account and call that to set the correct translation in dragBegin.
Controls are slided in by animating translationX from the actor's
width to 0; however as _updateTranslation() will skip the animation
when the property is already at its target value and 0 happens to be
the initial value of translationX, the initial animation is skipped.
Fix this by initializing translationX to undefined, which will always
differ from a valid target value.
The comment is right, updating the translation should be deferred
to pageEmpty, or else overview controls will just pop up instead
of sliding in. So revert that part of commit 6a7fa52879.
Providers that need drag-and-drop behavior can implement this via the
createResultObject() hook (as the app search provider already does), no
need to duplicate that code in the generic result objects
(ListSearchResult already does not implement DND).
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design mockups, animate the icons on AllView, FrequentView,
Dash and Search to zoom out when opening a new window of the app or when
the app is not running and the user execute it.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Given that we animate indicator in, it makes sense to animate them out
as well.
Also make possible animating indicators between view changes as well.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design decision, we want to animate AllView and FrequentView
when opening and closing with a swarm spring form.
This involves a few changes needed to allow that, since from some time
now, we are animating page changes in viewSelector, using only a fade
transition. However now we want to let appDisplay and iconGrid apply its
own animation.
For that we special case the change to and from apps page on
viewSelector to let appDisplay to animate its own items, using and API
on appDisplay which at the same time uses an API on iconGrid.
Thanks Florian Müllner for the debugging work
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Add a new animation to folder view based on designers mockups that
emulates pulsating icons.
The code on iconGrid is though to work well for the upcoming patches to
animate AllView and FrequentView.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
If you turn on natural scrolling, instead of swiping up, you need to
swipe down, which is bizarre. Just accept any type of scroll and have
them contribute to the delta.
https://bugzilla.gnome.org/show_bug.cgi?id=734874
This reverts commit a84fb99c0a.
This commit didn't make the OSK fully operational yet on Wayland, and
caused the double emission of key events on X11 due to the OSK keys
receiving first touch events from the passive touch grab, and then
emulated pointer events from event selection after the touch sequence
was rejected in the grab.
When we make a better effort at handling touch events just once on X11,
this commit can be reapplied and remaining wayland OSK support resumed
from there. In the mean time, this patch is better reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=735681
Commit bbfa616f27 renamed _ignoreRelease to _ignoreUntilRelease
in some places, but not others, which broke GrabHelper.ignoreRelease().
Complete the name change to fix the fallout (e.g. app launcher menus
closing on button release).
The code from PanelMenu.Button assumed menus would open below their
source actor, making KEY_Down a good choice; however with the new
generic code, we should base the key used on the actual menu position.
https://bugzilla.gnome.org/show_bug.cgi?id=735614
The behavior of opening/closing/navigating a menu from its source
actor is generic enough to not limit it to PanelMenu.Buttons, so
move the code into PopupMenu itself.
https://bugzilla.gnome.org/show_bug.cgi?id=735614
Since mutter commit 527c53a2a0582eba, MetaWorkspace::window-removed
is emitted *before* MetaWindow:workspace is updated, so the test
whether the removed window should still be on the workspace in
question will always return true.
Assume the test is no longer necessary nowadays to fix this very
obvious regression.
https://bugzilla.gnome.org/show_bug.cgi?id=735608
Currently we are removing tweens of the button and border, but not from
the title. That causes the title to be in wrong positions sometimes when
dragging windows on the overview, given that the slider is moving and
therefore the windows + overlay are moving too.
To avoid that, remove tweens of the title as well.
The code that loads SHELL_BACKGROUND_IMAGE, which is used to load the
performance background was loading it in WALLPAPER mode, not ZOOM
mode. Zoom mode is what we use for the actual GNOME defaultiwallpaper
and what we want to test: the background will be scaled except when
the resolution matches the 2560x1440 default backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=735385
Users can now toggle geolocation off/on from privacy panel of
gnome-control-center so we don't need to clutter the menu with a
settings that most users won't touch most of the time.
https://bugzilla.gnome.org/show_bug.cgi?id=731122
The scale passed to _updateChildrenScale is exclusively computed from
properties, so it can be moved into the function itself - as the scale
now becomes a mere detail, rename to a more appropriate _updateIconSizes
at the same time.
The existing code broke when commit 792b963bda changed the custom
result actor hook to return an object instead of an actor - stop
trying to go through a _delegate to make it work again.
Commit 14ceb10555 changed the "Open Calendar" item to open the
"recommended" calendar application rather than the default one to
avoid problems with MIME subclassing (namely falling back to the
default text editor when no calendar app is installed).
With this change however, the application launched does no longer
necessarily match the one configured in Settings, which is unexpected.
To avoid both problems, use the default calendar application again,
but only if it is in the list of recommended applications.
https://bugzilla.gnome.org/show_bug.cgi?id=722333
We need to put the actual actors in the history, not just the labels,
otherwise all emptyLine (which are not messages but are not empty
either) and all lines with a timestamp will get stuck in the scrollback.
https://bugzilla.gnome.org/show_bug.cgi?id=733899
We assumed that either a portal would give us a target URI, or we
would eventually reach the URI of our choice (which is http://www.gnome.org)
This is not always the case: even after a successful login we may
stay in a confirmation page, so make sure that every time we see a
redirect we trigger a connectivity check (or queue one for when
the user closes the window)
https://bugzilla.gnome.org/show_bug.cgi?id=733848
Search providers that should be disabled by default come with
a DefaultDisabled=true key in their keyfile, and are enabled
with the "enabled" whitelist, not with the "disabled" blacklist.
https://bugzilla.gnome.org/show_bug.cgi?id=734110
Performance testing was producing inconsistent values at different
times in the day since the GNOME default background is animated and
sometimes has a single layer, and sometimes two blended layers.
So we have consistent numbers, install a simple animated background
with GNOME Shell that has 40-year long transition ending in 2030,a
and set an environment variable in gnome-shell-perf-tool so that the
background is override with that background. (The background depends
on files installed by gnome-backgrounds; we assume that the person
running performance tests is doing so within the scope of a full
GNOME install.)
https://bugzilla.gnome.org/show_bug.cgi?id=734610
All derived classes are already checking explicitly for action names
(FOO and FOO_BACKWARDS). mutter used to have a META_KEY_BINDING_REVERSES
flag for keybindings which required special handling of "shift"+FOO as
FOO_BACKWARDS, but this has been removed now, so this special handling
is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
When this flag is set on a MetaKeyBinding, mutter will know that
the keybinding has an associated reverse keybinding triggered with
the shift modifier. However, an undesirable side-effect is that
gnome-control-center keyboard panel does not know that this 'shift'
is reserved for these reverse keybindings and cannot detect
conflicting bindings in this case.
This 'reverse' logic can now be handled at a higher level (in gcc keyboard
panel) so this commit removes it from gnome-shell so that they do not
conflict.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
Now that mutter gives a way to check if a MetaKeyBinding was marked as
'reversed' or not, gnome-shell does not have to hardcode that a
MetaKeyBinding using a shift modifier is reversed, it can directly check
if the appropriate flag is set.
https://bugzilla.gnome.org/show_bug.cgi?id=732296
We were setting the value of adjustment on size changes, but we weren't
changing the page value, so adjustment and page value was not in sync.
To fix it, make sure adjustment of the view is in sync with the page
value.
https://bugzilla.gnome.org/show_bug.cgi?id=734680
Since these settings are now going to be accessed by
gnome-control-center as well, its more appropriate for them to live in
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
Having the on/off setting be backed by a boolean in dconf makes sense
anyway but this is mainly to be able to remember the max accuracy set
before user disabled geolocation so that when they enable it next time,
we have the max accuracy level on same value as before.
There hasn't been a real need for this but now we are about to add
geolocation settings in control center and it'll be easiser for
control-center to simply toggle a boolean property rather than to have
to know about and deal with accuracy levels.
Later we might also want to add accuracy level settings to privacy panel
so keeping the accuracy level setting around still. However we no longer
support 'off' accuracy level as the new boolean property covers that.
This also implies that we no longer track available accuracy level,
which made the code a bit hard to follow/maintain.
https://bugzilla.gnome.org/show_bug.cgi?id=734483
The zooming animation of the windows looks nice when animating
from the workspace display page, but looks weird from other pages
like apps page or search page since the windows come from nowhere
with an initial position not known to the user.
Instead of that just fade the desktop with the windows in its
original position.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
Currently we are overriding the explicit calls to slideIn
given that it's called also with the signal of showing overview.
It was necessary because of the bug that previous patch fixed,
so now we can just delete that.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
The slide of thumbnailWorkspace is shown when entering overview,
connecting to the same signal that creates the thumbnails, the showing
signal of overview, but, to make the slide animation we need to know how
much width the slider has. To do that we ask the thumbnailsWorkspace
about its width, but given that it connects to the same signal it could
ask the width without having created the thumbnails yet, so reporting a
width of 0 and confusing the slide animation.
Currently it works because gjs calls the callbacks following the order
of the clients connecting that signal, and the thumbnailsWorskpace is
connected before the slide ones.
To avoid that we allow to request the preferred size of the
thumbnailsBox at any time with any number of thumbnails. The only thing
required is to make sure the porthole is accessible when requesting the
preferred size.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
We were calling twice showPage() with the correct page, here and in
show() / zoomFromOverview given that _resetShowAppsbutton was called
from the signal 'showing' of overview. Given that the call to
_resetShowAppsbutton is only actually used when hiding the overview we
can actually put the checked state of the button to false when animating
from overview so it shows the workspace page, causing the same behavior
of _resetShowAppsbutton without all the shenanigans of resetting when
the hiding overview signal is triggered.
https://bugzilla.gnome.org/show_bug.cgi?id=732901
Currently the indicators are a BoxLayout inside a BinLayout in AllView.
BinLayout doesn't have any size constraint, so if the indicators request
a bigger size than AllView the entire overview is grown, causing the
overview to go crazy.
To avoid that, create an actor for the page indicators that request as
minimum size 0, and as a natural size, the sum of all indicators natural
sizes. Then we clip_to_allocation, so it doesn't grow more than the
parent.
https://bugzilla.gnome.org/show_bug.cgi?id=723496
If the application reports itself as single window (through
an explicit indication in the desktop file or some heuristics),
not show a "New window" item that doesn't actually open a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=722554
Both Panel.ActivitiesButton and its parent class Panel.MenuButton would
attempt to connect their own _onEvent() function to Clutter::event,
which counterintuitively was connecting the child class' _onEvent()
function twice.
So, actually chain up on the signal handler, and don't connect twice
to the signal. Both methods were calling this.menu.close(), so only
do that on the parent class handler, since we're chaining up and doing
the right thing now.
https://bugzilla.gnome.org/show_bug.cgi?id=733840
We don't need to wait to until the stage window is mapped to take
the modal grab, because that code now runs in a startup-prepared
signal handler, which in turn runs some time after the mainloop
has started and well after the stage window is mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=711682
The grab would previously just consume the button release, while propagating
motion events, possibly down to clients in wayland. This would produce
inconsistent streams there.
On pointer events, the inconsistency would just be having clients receiving
events with the button 1 set in the mask, with no implicit grab. When touch
events are handled, this would be more hindering as the client would receive
touch_motion events with no prior touch_down nor later touch_up, something
never supposed to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
The animation is the same for modal dialogs, but it is now
run for non modal dialogs too (matching the new behavior on
show).
In addition, we run a destroy animation for normal windows,
if they use CSD (there are technical limitations that prevent
running animations after destroy on server decorated windows)
https://bugzilla.gnome.org/show_bug.cgi?id=732857
Handle touch events, so that an interacted button locks to a single sequence,
but multiple sequences are free to interact with multiple key buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
The long press code has been refactored so it can be used on both pointer and
touch events, and the click gesture has been made to account for button=0.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
No sequence checks are done, these UI elements promptly trigger a grab that
will cancel ongoing touches and redirect later ones somewhere else, so that
works as a barrier to multi-toggling.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
This adds a table with mappings for GNOME apps that have recently
renamed their desktop files, and uses that to update the desktop names
saved in user settings with the new values.
https://bugzilla.gnome.org/show_bug.cgi?id=729429
Currently to know how many results we could show for GridResults
we use the width of the bin containing those results. Since it's
expanding it shouldn't be a problem. But it becomes a problem when
no results are displayed, thus the container becomes hidden and
it losts its allocation.
In the next introduction of terms in search we call again
maxDisplayedResults but it doesn't have allocation yet, and therefore no
results are displayed (currently a bug on IconGrid makes the min size =
one icon, so actually we show one and only one icon in this case).
To solve that use the parent container which contains the search results
of all providers or the text label with not displayed results, so it
always have the real available width to calculate maxDisplayedResults.
Thanks Alban Browaeys for the debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=732416
Unlike for the main app view, where we only move the key focus once the
users starts navigating, the key focus is moved immediately when opening
a folder popup. This is unexpected, so make app folders consistent with
the main view.
As arrow keys will not work while the container itself has key focus, we
handle those explicitly by translating them to TAB_FORWARD and
TAB_BACKWARD respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=731477
Support was added to Mutter to allow it to trigger a restart
to allow for restarts when switching in or out of stereo mode.
Hook up to the new signals on MetaDisplay to show the restart
message and reexec. Meta.is_restart() is used to suppress
the startup animation.
This also allows us to do 'Alt-F2 r' restarts more cleanly
without a visual flash and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
Instead of always logging frame timestamps for every frame - which
was using >26 bytes of memory per frame, or 5MB per hour of continuous
redrawing - make frame timestamps something that defaults off and is
turned turned on using a new ShellGlobal::frame-timestamps property by
the perf scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
Add an option for windows created with Scripting.createTestWindow()
to continually redraw themselves; this is for testing performance
of application updates.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
We currently replay events that should start a search to the search
entry, which is fairly dodgy. Synthesize a new event with the correct
source actor instead, which is a bit less evil.
If an active grab on pointer events happens during multi-touch operations,
all non-pointer-emulating touches will be muted. This may leave the
Clutter.ClickAction incomplete if triggered by one of those sequences,
just to have a gesture take over and trigger a compositor grab, which would
leave the capture-event handler stuck eating events.
So listen for grab-op-begin from the display, and ensure the action is
released if such grab begins.
and the capture event handler stuck.
When returning to the desktop from overview we always show the
workspaceDisplay, given that is which have the windows clones to allow
animations.
The problem becomes when previous that we were at some other
page, like Search or AppDisplay. The problem is that when showing the
workspaceDisplay the windows are repositioned. That's wanted except
when returning from overview, since that causes unwanted animations
of the windows.
To avoid that just not reposition the windows if leaving the overview.
We don't normally hit the code in scripting.js to print metrics
because shell-perf-tool bypasses it, but there was a left-over
in the code that no longer works. Also add in the units to the
output.
https://bugzilla.gnome.org/show_bug.cgi?id=732349
If reusing an existing separate builddir, the generation of dependencies
for the JS resource file would fail because it couldn't find misc/config.js,
resulting in the resource file not being regenerated.
https://bugzilla.gnome.org/show_bug.cgi?id=732348
Listen to changes in connectivity, and ask our helper to authenticate
when needed.
We don't have a URL to connect to yet (we will have when
the new NM API lands), so we use the default of trying
www.gnome.org (which is also more reliable because we can
recognize when the login is done)
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Add a small DBus-activated GtkApplication that embeds a WebKitWebView
and implements some minimal logic to see if the login succeeds.
It will try to connect to a custom NM-provided url (the portal login
page), if one exists, or to www.gnome.org in the normal case of
a portal doing redirect.
https://bugzilla.gnome.org/show_bug.cgi?id=704416
Icons inside the menu are updated only for device state change,
but for the main device they also depend on connectivity (which
is a global property).
Add a public method to force an update of the icon, and call it
when connectivity changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726401
They are different properties, they deserve different syncs.
Especially because a full allocation cycle sets both anyway, so
we should save some cycles this way.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We already have the width and height information cached in JS,
let's avoid going through gjs-gobject-clutter to retrieve them
again. As a plus, with normal properties the optimizer should
be able to generate better code.
https://bugzilla.gnome.org/show_bug.cgi?id=729823
We must remove the old image from the cache, not the new one.
This was causing a leak of old (and expensive) background
images, and was causing errors at the end of animations, trying
to destroy the animated background.
We translate 'On' to available accuracy level but if available accuracy
level later changes, we don't update available accuracy level accordingly
and hence limit the accuracy of apps.
E.g if available accuracy level is 'city' and geolocation is enabled,
the max accuracy level would be 'city' and apps can't get higher than
that. Now if user plugs in GPS, the available accuracy level will change
to 'exact' but without this patch max accuracy level will remain to be
'city' and apps will not be able to use the GPS.
https://bugzilla.gnome.org/show_bug.cgi?id=731882
The code currently tries to use Meta.KeyBindingFlags.REVERSED. Since
this constant is |'ed with Meta.KeyBindingFlags.REVERSES, gjs silently
ignores the unknown flag.
https://bugzilla.gnome.org/show_bug.cgi?id=731619
Commit 5d00c1a5ee moved app folder popups to GrabHelper - for some
reason, the line that ensures the current behavior of only considering
events inside the app picker to dismiss popups got lost ...
As clicks outside the app picker should still be handled normally
while clicks inside should dismiss the popup, we cannot make full
use of GrabHelper. However using it at least for focus handling
fixes some minor details we are getting wrong, for instance not
restoring the previous focus after dismissing a folder popup.
Commit 6c2f3d1d17 moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.
Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
https://bugzilla.gnome.org/show_bug.cgi?id=695487
The 0x0 dummyCursor works well when the menu pops up directly underneath
the pointer (e.g. when triggered by right-clicking the titlebar) or by
keyboard, but not when triggered by the menu button - the menu does not
point to the center of the button's bottom edge, and unless the user
keeps holding the mouse button while moving into the menu, the menu will
be dismissed immediately on button release.
Address these issues by using the button geometry to overlay the window
button with an appropriately sized actor that acts as a proper sourceActor,
to make the window menu behavior consistent with other shell menus.
https://bugzilla.gnome.org/show_bug.cgi?id=731058
Having the full geometry of the menu's source button (if any) will
allow us to address several misbehaviors of window menus, so use
that instead of show_menu().
https://bugzilla.gnome.org/show_bug.cgi?id=731058
When the pointer leaves the notification area, we queue a timeout to
hide the notification after a little while. If the user is hovering over
a notification and clicks the X button to close the notification, we will
destroy the notification, which causes a "pointer left" event on the
notification area. This queues a timeout which erroneously fires after
the next notification in the queue shows up.
The code and state machine are too complex to properly make sure this
timeout doesn't fire when there is no notification up next, so instead
just clear it when showing a notification to make sure that any
previously queued timeout doesn't apply to us.
https://bugzilla.gnome.org/show_bug.cgi?id=731118
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
We don't make use of any functionality StTable provides over
ClutterTableLayout, so port all users to the Clutter layout
in order to remove our own copy of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=703833
It is a bit odd to request AM/PM format when the locale selected
by LC_TIME lacks the concept. We ignore the format setting in that
case elsewhere and assume 24-hour format, let's do the same for
chat timestamps for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=728271
When workspaces are disabled by the session mode, all workspace
related actions don't make sense. Worse, the "Move to Workspace ..."
actions allow sending windows into a nirvana with no means to
get them back.
https://bugzilla.gnome.org/show_bug.cgi?id=730653
Starting keynav into the active page is handled from a key-press
handler on the stage, however we should not "start" keynav when
we are already navigating elsewhere - the latter can happen when
keynav fails (for instance because the focus is trapped inside an
open app folder or at the end of the dash), and the event bubbles
up to the stage. So make sure to only handle the event to actually
start keynav, to not interfere with the normal navigation handling.
Thanks to Carlos Soriano <carlos.soriano89@gmail.com> for the
debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=726760
The fallback app-menu in GTK+'s client side decorations obviously
uses the GTK+ theme rather than the shell one; update the style
of our own fallback app-menu to resemble that style.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
We now allow "appmenu" in the button layout to make synchronizing it
with GTK+'s client-side decorations easier, but as some people tweak
their settings to get in-window app menus even when using the shell,
actually pop up the app menu when the button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
The optional label support introduced in commit af063dc2f2 broke
the centering of separators, as the label still adds additional
spacing even when empty.
Properly hide the label actor in that case to fix the alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=730753
The extension-prefs tool is used by gnome-tweak-tool and the
extensions web site to display preferences. However as those
already implement their own extension lists, the main window
is not useful in that context (to not say it is rather silly).
Just skip the main window and only show the specified extension's
preference dialog in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
Bring the extension-prefs tool in line with the mockup by adding
switches to enable/disable extensions, similar to the extension
page in gnome-tweak-tool.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
The extension-prefs UI has never been great, but as the GNOME 3
design patterns are evolving, it is starting to look seriously
outdated. Modernize the UI a bit to have it fit in a bit better.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
When a monitor is removed, the OsdWindow for that monitor may process
the monitors-changed signal before OsdWindowManager does (which will
remove the OSD). If that happens, we will currently try to access
an invalid monitor; check for this to avoid a couple of warning.
When switching between alternatives in AltSwitcher, the currently
visible child is replaced with the alternative. If the original
child has the key focus when it is removed from the stage, the
focus is lost. Detect this case and manually move the focus to
the new child.
https://bugzilla.gnome.org/show_bug.cgi?id=727259
When dragging a window preview from a non-primary monitor onto a
workspace thumbnail, the window is moved to the primery monitor
first before changing its workspace. However when dragging the window
between thumbnails to create a new workspace, it is kept on its current
monitor instead. This is not only inconsistent, but outright confusing
with the default 'workspaces-only-on-primary' setting, as the newly
created workspace is immediately removed again.
https://bugzilla.gnome.org/show_bug.cgi?id=683819
We only need GSystem when running under systemd. As libgsystem itself
has a hard dependency on systemd, only import it when actually needed
to keep working on systems where systemd is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=728449
The workspace switcher should be expanded when workspaces are in use.
Our current implementation assumes that workspaces are used when there
are windows on at least two workspaces. However workspaces are already
used when moving from a non-empty workspace to an empty one (presumably
with the intention to launch something on that workspace), so tweak the
heuristic accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=662457
Having the ability to go to the current date if the user is already
on the current date can be confusing. So don't make the button reactive
until the selected date changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726724
Currently, our logic for page panning isn't great. If the user starts a
pan upwards and hesitates over a new page, we'll go to the *next* page
on release, since the difference is greater, but the velocity wound down
to 0.
Instead of trying to treat it like page down or scrolls, simply do the
math to find the page where the user scrolled to.
This is unfortunately broken for fast swipes, since the user doesn't get
far enough into the new page to make a difference. I'm getting the
impression we'll need a gesture recognizer for this, though, however
crude. Simple hacks I tried, like a velocity multiplier, didn't work
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=729064
We often call goToPage like:
this.goToPage(this._currentPage - 1);
(or + 1). During panning, these are based on the velocity values
of the gesture action. If we're already on the first or last page
and the panning ends, it's possible to get goToPage that's either
-1 or greater than the last page.
During normal usage, this isn't a problem, since the Y values will
be correct, always. But when panning, the Y values stick to the
finger, and thus if we return early, we won't snap to the exact page,
making it seem like things get "stuck".
Fix this the simple way by clamping to the correctly-ranged values
of pageNumber
https://bugzilla.gnome.org/show_bug.cgi?id=729064
The order in which month and year are displayed is controlled by
a "special" translated string in GTK+. We pick up the translation
from there, so make sure that it doesn't get translated again
in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=715042
When workspaces have been removed, we need to remove the corresponding
thumbnails as well; the number of thumbnails that need removing is
the difference between the old number of workspaces and the new one.
Currently we assume that the old number of workspaces corresponds to
the number of existing thumbnails, but that may actually be wrong:
A thumbnail will still be animated out after its workspace has been
removed. As a result, we end up removing too many thumbnails when a
workspace is removed while a thumbnail of a previously removed workspace
is still animating out. Fix this by basing the old number of workspaces
only on thumbnails that have not been removed previously.
https://bugzilla.gnome.org/show_bug.cgi?id=728820
Taking an area screenshot doesn't work currently when in "grab mode",
for instance when the message tray or top bar menus are open. Fix
this by using GrabHelper for selecting the area, so grabs are properly
stacked for us.
https://bugzilla.gnome.org/show_bug.cgi?id=709126
The code path is completely unmaintained and untested (and probably
unused as well, considering that nobody has complained about accessing
the session object's Active property which does not exist in the
ConsoleKit case).
Most of our ConsoleKit code is already a dummy anyway, just do the
same for the remaining functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=686626
Commit 7101cc3170 caused a small
regression insomuch that it checks for a valid "level" but simply using
"if (level)" which will be false if level is undefined and if
level == 0.
Check for not undefined instead.
https://bugzilla.gnome.org/show_bug.cgi?id=727384
Sometimes it is more appropriate to set layout properties that are
hooked up to CSS properties in code. However this is currently not
possible, as we end up setting properties to 0 when not found in CSS;
be a bit more careful when hooking up CSS properties to support this.
https://bugzilla.gnome.org/show_bug.cgi?id=728897
When we unregistered providers, like when we refreshed the list of
active remote providers, we would forget to destroy the old provider
display after the fact. This left an empty "skeleton" provider display
still in the search results that would never be filled in. Make sure
to destroy it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=728597
We had one osdWindow that we displayed either on the primary monitor or on
whatever monitor index got passed over dbus.
Change that to show the osd on all monitors when no explicit monitor is
requested. A monitor should be requested in cases like display brightness where it makes sense to only show the osd on the affected monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=722684
NetWM struts are defined in terms of screen edges (rather than monitor
edges), which works poorly with vertical monitor layouts (as it renders
entire monitors unusable). Don't extend struts in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=663690
Calling Mainloop.source_remove() on the timeout ID will not reset it,
and we're already removing the timeout by returning GLib.SOURCE_REMOVE
in the callback.
If geoclue reports that we can't aquire location, we hide the menu. This
will typically happen when user is offline (and doesn't have a 3G
modem). This is likely not what we want since this like a temporary
situation and user would want the ability to toggle geolocation still
even if its currently not possible any applications to query the
location.
https://bugzilla.gnome.org/show_bug.cgi?id=727398
We need to use a GdkPixbufLoader instead of the straightforward
gdk_pixbuf_new_from_file(), since we want to load the image already
scaled if possible - e.g. if it's an SVG file.
https://bugzilla.gnome.org/show_bug.cgi?id=726907
* 'Turn On' -> 'Enable'
* 'Turn Off' -> 'Disable'
* 'Off' -> 'Disabled'
* 'On' -> 'In Use' or 'Enabled' depending on whether or not service is
in use.
https://bugzilla.gnome.org/show_bug.cgi?id=726498
Telepathy 1.0 will not be compatible, and will probably require
source changes. telepathy-glib 0.12 and telepathy-logger 0.2 are
the 0.x ABIs (they were the first stable-branches to have g-i).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=721704
Reviewed-by: Giovanni Campagna
When a user logs in to a wayland session, we keep the login screen
running on the X server with the login screen running in a deactivated mode.
This commit makes sure it get reactivated when the user comes back to
the VT (from user switching, logout or just ctrl-alt-f1).
https://bugzilla.gnome.org/show_bug.cgi?id=726989
In addition to BluetoothAirplaneMode, we need to check also
BluetoothHasAirplaneMode, which is indicative of bluetooth rfkill
devices (and by extension bluetooth adapters).
This prevents showing the menu if there is no adapter present.
https://bugzilla.gnome.org/show_bug.cgi?id=725057
Most system menu entries are disabled on the lock/login screen;
there is no good reason why users should be allowed to turn bluetooth
on/off (but not e.g. Wifi), so disable the entry as well.
https://bugzilla.gnome.org/show_bug.cgi?id=726319
When reacting to background settings changes, we may end up queuing
more than one load. The redundant backgrounds are expected to be
destroyed when the previous background has faded out; however since
commit 933f38390b, the tweened actor is the same for all
consecutive load operations and we end up with a single onComplete
handler, ergo a single destroyed actor.
As new backgrounds are always added to the bottom, we are not only
piling up additional background actors, but break changing backgrounds
more than once, as the correct background ends up being covered by
previously added redundant actors.
Fix this by destroying redundant actors right after loading rather
than waiting for the fade animation to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=726120
Folders use a 2x2 grid of the first 4 app icons as icon - if a folder
contains less apps, we currently skip the corresponding grid positions.
As a result, the overall size request may be smaller than the one for
other icons, making the folder icon look out of place.
Fix this by always using a full grid as folder icon, using dummy actors
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=726322
At some point ScreenShield had code to do this, I don't know when
it was lost, but it makes sense and avoids having to move the mouse
just to see the shield.
https://bugzilla.gnome.org/show_bug.cgi?id=726378
With the switch to a table layout in commit f959cafb36, setting
alignments to place the individual icons at the outer edge of the grid
stopped working. Remove that code and add some explicit spacing instead.
https://bugzilla.gnome.org/show_bug.cgi?id=726323
If the notification is updated while SHOWING, we'll overwrite the
tween updating it to the new 'y' position, but forget to update the
state to SHOWN at the end of our transition. Make sure to always set
the state to SHOWN at the end.
https://bugzilla.gnome.org/show_bug.cgi?id=704844
This code may have worked when written in 2009, but later gjs commit
b5e467d89aea43a8e32a1138d232c8a32e6b0785 removed the priority
parameter from idle_add.
Now, when running a constantly-updating client (es2gears) on an
embedded platform, _updateRegions() does not get called and I see
unresponsive window decorations.
Update the code to use meta_later_add() like other parts of the
shell, which is actually slightly better in this case anyway.
Solves the unresponsiveness problem.
https://bugzilla.gnome.org/show_bug.cgi?id=585500
The smartcard service is put in the foreground in two cases:
1) If password service is disabled by admin configuratoin
2) if a smartcard is inserted
In either case we don't want to ask the user to pick a user from the
userlist. We currently only avoid asking in case 2.
This commit fixes case 1.
https://bugzilla.gnome.org/show_bug.cgi?id=726263
We only want to react to the card the user logged in with, at
the unlock screen. We check "at the unlock screen" by checking
the "reauthenticating" state variable. That variable is the
wrong one, though. It gets set too late, and in some cases, gets
set at the login screen, too. We should be checking this._reauthOnly
instead.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=726262
If a user inserts the smartcard they logged in with into the system,
it's supposed to lift the shield and prompt for pin. That doesn't
happen because the parameter list of the smartcard-inserted signal
handler is wrong.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=726262
Doing so is inconsistent with the behavior in the summary, and
is quite annoying when dealing with chats (because there is no way
to unfocus a chat notification with the keyboard only)
https://bugzilla.gnome.org/show_bug.cgi?id=724178
We can't let live (ie, never destroyed) actors undergo GC, because
they will emit :destroy signals during finalization and assert/crash
libmozjs. Properly destroy all actors before letting the GC
free them.
https://bugzilla.gnome.org/show_bug.cgi?id=724798
If we have the following sequence:
cache.getImageContent({ filename: "foo", cancellable: cancellable1 });
cache.getImageContent({ filename: "foo", cancellable: cancellable2 });
cancellable1.cancel();
Then the second load will complete with "null" as its content, even though
it was never cancelled, and we'll see a blank image. Meanwhile, since the
second load simply appends to the list of callers for the second load,
cancellable2 does absolutely nothing: cancelling it won't stop the load,
and it will still receive onFinished handling.
To prevent this from happening, give the actual load operation its own
Gio.Cancellable, which is "ref-counted" -- only cancel it when all the other
possible callers cancel.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
At the moment when a file is loaded, we iterate through the list of
pending file loads and ignore any unrelated to the file, then iterate
all the callers of the related file loads and finish them.
In fact, there can only ever be one pending file load related to the
file, and we already know it, so we can avoid the ugly nested loops.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
This commit moves the code around a bit such that the
caller gets allocated up front and then a file load is either
found or created to attach the caller to.
Functionally, the code is the same, it's just now factored in a way
that will make it easier to fix a bug with cancellation later.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Copying is actually a lightweight operation, so trying to avoid it just adds
code complexity for little gain.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Instead of poking through IDLETIME, which confuses the state tracking
and can prevent automatic suspend, send a special signal to GSD
when the screen is to be waken up for a notification.
Someday we'll bring over all the state tracking and avoid this
ping-pong between gnome-shell and gnome-settings-daemon, but
that day's not today.
https://bugzilla.gnome.org/show_bug.cgi?id=712706
NMApplet will call removeConnection() unconditionally on all sections,
including those that had nothing to do with the connection in the first
place.
Fixes:
Gjs-WARNING **: JS ERROR: TypeError: this._connectionItems.get(...) is undefined
NMConnectionSection<.removeConnection@resource:///org/gnome/shell/ui/status/network.js:323
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._connectionRemoved@resource:///org/gnome/shell/ui/status/network.js:1885
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=725958
Loading the user list can be expensive, for instance when there is
a large number of users and/or their avatars have to be fetched over
the network. In case the user list is disabled anyway, there is no
point in doing that work just to hide it, so stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=725905
When the user changes the active day by mouse click or keyboard focus
plus key press on a day in the grid, always move the keyboard focus to
the newly activated day.
This basically restores functionality that was introduced in commit
31478e9fb4 but got lost again in the re-factoring in commit
cc4659f5c6.
https://bugzilla.gnome.org/show_bug.cgi?id=725606
Having to go through import.gi is awfully inconvenient when one
is using the looking glass as a quick gjs console, and we're
already importing all sorts of stuff there.
https://bugzilla.gnome.org/show_bug.cgi?id=725832
Don't forget to rebuild the calendar when changing the setting
'org.gnome.shell.calendar show-weekdate'. This wasn't happening anymore
and changing the setting resulted in a calendar without the days
grid.
https://bugzilla.gnome.org/show_bug.cgi?id=725533
Once you start navigating between months, you can't return to the
current day. However, the current day is always displayed above the
calendar grid. Fix this by making the current date clickable; when
clicked, the calendar grid jumps back to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=641366
The profile name is most often not useful (because it's an
autogenerated string like "Wired Connection 1"), and even when it
is, it's already available in the submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=725586
Commit b7e1539699 removed the size to support hidpi but that caused the
actor to no longer be square. Fix that by going back to setting a size
but apply the scale factor before doing so.
To be able to correctly setup dbus policy, I had to change the expected
agent D-Bus API a bit: Now object path is fixed and not different for
each user.
https://bugzilla.gnome.org/show_bug.cgi?id=725082
Commit 61a58ff3c9 replaced the (removed in commit 254afc50223a7)
MetaWindowActor.get_workspace() method by MetaWindow.get_workspace(),
but did not take into account that the return values differ - the
former returns the workspace index, the latter the workspace object.
https://bugzilla.gnome.org/show_bug.cgi?id=724686
With tile previews being implemented as Clutter actors in the shell, we
can now easily add fancy animations when showing/hiding the preview.
Besides looking more polished, the animations also help understanding
what will happen to the window when the drag is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=665758
Interrupting update installation can mess up the package database quite
a bit and could lead to totally destroying the distro installtion. To
avoid running out of juice during an upgrade, warn when someone tries to
install updates on battery power.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
This adds a checkbox for installing software updates to the shut down
dialog. The implementation relies on an already prepared offline update
and uses PackageKit's pk-trigger-offline-update helper to trigger the
installation.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
This moves the dialog type overriding that gnome-software uses to bring
up restartInstallDialogContent from _sync() to OpenAsync(), in order to
ensure the type is overridden early enough to show the correct buttons.
While at this, make sure the & symbol in the button's label is escaped
to avoid runtime warnings, now that the label actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
Currently workspaces (except for the last one) are removed when
they become empty. While we do have special treatment for the
case where the currently active workspace is removed, we just
move directly without animations to the last workspace to avoid
ending up on a "random" workspace. However this behavior is still
a bit confusing, so keep the workspace around instead until the
user decides to move to another one.
https://bugzilla.gnome.org/show_bug.cgi?id=709064
Add a key 'disable-extension-version-validation' key that disables
the validation of extension's claimed to be supported shell version
with the shell version and just load all extensions unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=724683
Until now the arrows were the associated arrow
character of the font. This cause some problems like
different arrows for different fonts, and size can be
altered because of the font size.
To solve that, use an image for the arrows.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently the animation of the arrows doesn't take
into account previous rotation.
Since in a incoming patch we will use one arrow
and rotate it to generate the four directions, we
need that the animation use relative rotation.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently destroying a menu's actor and calling its destroy() method
are subtly different - the latter will also result in the menu being
removed from the corresponding menu manager.
There is no good justification for that behavior, so make both actions
behave the same.
https://bugzilla.gnome.org/show_bug.cgi?id=724690
Until now the timestamps were using 24h format.
Check gsetting clock-format to know when
the user is using 12h format or 24h format and
make the timestamp acordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=715158
Multiple connections for the same device are mutually exclusive, so
a switch is not the appropriate UI metaphor. Use a radio item instead,
and provide a separate "Turn off" item to disconnect.
Behavior when there is only one connection is not changed, there
is a single Connect/Turn off item.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
We don't watch for timestamp changes, and sorting by name keeps
the order consistent and predictable. In practice, there should
be at most 3 or 4 elements, so the user will always read all them
at once and sorting is irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
If the connection name is changed, the UUID doesn't necessarily,
so checkConnection would take the early return path. Make sure
we update the existing menu item too.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
The active_connection might be null, but the NMApplet code might
still belive the device wrapper is the primary connection (because
dbus signals are emitted one after the other).
(Also, remove an old and wrong comment about bluetooth in wwan code)
Fixes:
(gnome-shell:22511): Gjs-WARNING **: JS ERROR: Exception in callback for signal: icon-changed: TypeError: this._device.active_connection is null
NMDeviceWired<.getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:475
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._updateIcon@resource:///org/gnome/shell/ui/status/network.js:1790
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionSection<._addConnection/<@resource:///org/gnome/shell/ui/status/network.js:265
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionItem<._sync@resource:///org/gnome/shell/ui/status/network.js:137
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionItem<.setActiveConnection@resource:///org/gnome/shell/ui/status/network.js:169
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionDevice<._activeConnectionChanged@resource:///org/gnome/shell/ui/status/network.js:327
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=723570
This reverts commit 5d05b66902.
Had a long discussion with Bastien Nocera and Allan Day on IRC about
this and in the end we decided to go with the simple on/off controls for
now.
Conflicts:
js/ui/status/location.js
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Add more time to the fade in/out animation when switching
views so they don't switch abruptly and add a delay
between view switch animations to avoid morphing.
https://bugzilla.gnome.org/show_bug.cgi?id=722331
Split the current implementation of SourceActor into
SourceActor and SourceActorWithLabel.
In this manner we can use source actors withouth count labels,
required in the screenShield to not clash with the count
text label.
https://bugzilla.gnome.org/show_bug.cgi?id=709275
When exact accuracy (i-e GPS) is available, allow user to disable that.
When users don't want application to get their precise location, they
can now opt for network-based geolocation only, which can be
street-level at best.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Instead of relying on geoclue to store this user configuration, lets
keep it in gsettings. Geoclue is a system service and therefore is not
the appropriate entity to keep this info.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Instead of overriding the actor's request with the icon size, just set
the new icon size on the actors, and let the default handler take the
preferred size of children.
https://bugzilla.gnome.org/show_bug.cgi?id=705410
Now that we are indicating 'geolocation in use' to user, we better also
provide at least a way to disable geolocation. Once this is in place, we
can provide slightly better controls rather than simply on/off switch.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
The current middle-click action of opening a new window on a new
workspace is a bit peculiar; it is also not overly hard to achieve
the same result by moving a new window to the desired workspace or
selecting a workspace before opening a new window. Just opening
a new window is also a more common action, so having a shortcut
available that doesn't require a modifier is a good idea as well;
change the middle-click behavior accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Having terminal launchers behave differently than any other launchers
is non-obvious and confusing. Remove the special-casing to restore
consistency, we will make the new window action more accessible
instead.
This reverts commit 68faba6bde, 4ed0f3e5f0
and 887a21afb9.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
The design says that the noise texture is the implicit bottom
layer, and so it's appropriate to use it togheter with the default
color to cover the dead area outside the screen which becomes
visibile when scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=724305
In addition to checking the current settings, check also if the
zoom region is active before registering the event listener.
This way, we avoid DBus traffic for events we're not interested in.
Also, make FocusCaretTracker resilient to multiple register/deregister
calls (which can now happen).
https://bugzilla.gnome.org/show_bug.cgi?id=724305
It's possible that the DBus call goes in timeout (which is bad,
but unavoidable, given that atspi is synchronous) or fails
because the component has been removed (race condition). Those
errors are not dependent on gnome-shell, but on faulty applications
(mostly).
If they happen, log a debug message and continue.
https://bugzilla.gnome.org/show_bug.cgi?id=724305
If an actor is destroyed, calling get_transformed_size()/position()
can return bogus values and trigger JS exceptions.
This can happen if a tracked actor comes from an extension
(such as classic mode's window-list) and that extension is
deactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=723661
This reverts commit a36bfced47.
get_available_connections() returns the connections that are
available right now, ie, with the currently visible APs, but
that might change while the dialog is open, so we can't use it.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
To distinguish the bluetooth network menu from the bluetooth
menu proper, use the device name as the label.
Also, replace Connect with "Use as Internet connection"
https://bugzilla.gnome.org/show_bug.cgi?id=709353
The design says "when a network cable is connected", not
"When a network cable is connected and the link is up and we
have an IP etc. etc." (which is what ACTIVATED would imply).
https://bugzilla.gnome.org/show_bug.cgi?id=723570
Rather than just showing "No networks", inform the user if airplane
mode is on or if wifi is off, and allow the user to change that
from the dialog (if possible).
https://bugzilla.gnome.org/show_bug.cgi?id=709128
Ideally, we should keep scanning while the dialog is open, and
stop (or reduce the frequency) when it's closed. Forcing a new
scan when the dialog is opened empty is a close approximation
and increases the probability that the user will find the AP
he needs.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
If airplane mode is enabled with an HW switch, we can't turn it
off from the menu, so make the menu item insensitive and
replace it with a helpful tip.
https://bugzilla.gnome.org/show_bug.cgi?id=709685
The unredirect feature does not apply to the magnifier and it
prevents users from gaming whilst it is on so disable when magnifier
is active and allow magnifier users to game!
Bug https://bugzilla.gnome.org/show_bug.cgi?id=708985
The DESKTOP window might not be located at (0,0), in particular
on multi-monitor setups. While we already consider this by setting
the clone's position, we then stuff the clone into a container which
ignores it - meh ...
https://bugzilla.gnome.org/show_bug.cgi?id=723306
If the user mostly uses the All Apps view and uses it as his default view,
we shouldn't reload frequent data after a timeout. Simply do it when the
view is mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=723179
Need to manually dispose of cairo contexts used in gjs with $dispose(),
or the context object will leak. These classes used cairo for drawing but
were missing the dispose call.
https://bugzilla.gnome.org/show_bug.cgi?id=722812
get_categories() returns an unparsed string, not a list of categories.
We need to parse the list by splitting on ';' to deterine whether the
actual 'TerminalEmulator' category is in the list, rather than something
like 'X-GNOME-TerminalEmulator'. It's an edge case, but I need to split
the list properly for the new folders, so I might as well fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=723179
It's a lot simpler and doesn't require us routing the NMRemoteSettings
all the way through. It's still a bit complicated to do this for the
usual connections, so let's drop it for now.
Because we were setting this.background before calling .destroy(),
the call that was meant to destroy the old background was actually
destroying the new one!
https://bugzilla.gnome.org/show_bug.cgi?id=722787
When restricting the switcher popup to the current workspace, we
filter out running apps with an empty window list (namely: no open
windows on the current workspace). However we may end up with an
empty window list even when not restricting items to the current
workspace when all windows of a running app are associated with a
different application via the transient_for hint.
To fix this, just filter out items with an empty window list
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=722434
Without special-casing, our current spacing calculation results in
negative size requests for empty lists, which will trigger a Clutter
assert later.
While the list is never supposed to be empty, bugs happen; crashing
users' systems is the least graceful way of handling this, so don't
do it.
https://bugzilla.gnome.org/show_bug.cgi?id=722434
Using the new list_actions() API in Gio, add entries for static
actions specified in .desktop files in the right-click app menus,
in the dash, app well and search.
https://bugzilla.gnome.org/show_bug.cgi?id=669603
The window clones in the central part of the overview are showing modal
dialogs now, and this creates an inconsistency if the thumbnail doesn't too.
Code is intentionally similar in the two places.
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Windows in the overview should be like they appear in the workspace,
including modal dialogs that are attached above them.
In addition, hiding the dialogs in the overview causes a flash as
dialog appears at the end of the transition.
Based on a patch by Maxim Ermilov <zaspire@rambler.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Use a new ShellGLSLQuad actor class to build a RadialEffect that can be
enabled on Lightboxes to achieve a radial effect similar to the overview
one. Then enable it for modal dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
If the notification is destroyed between an allocate and the redraw,
the meta_later is invoked on a destroyed object, and fails because
the clutter calls are invalid at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=722547
By default, gesture actions no longer wait for the dnd threshold to
be reached before triggering, which breaks our mixing of click- and
pan actions. Fix this by only panning after reaching the threshold
and letting the click action go through if the pan is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=722417
This is done for properly drawing popup menu when arrow rise is 0 (in
case of background menu).
Normally, the menu with arrow rise set to 0 is drawn properly having
all four corners rounded. But when the source(click/arrowOrigin) is
near screen's edges, one of the corners (depending on source's position
and arrow alignment) is drawn right angled.
This happens because the rounded corners are skipped and right angled
arrow is drawn when arrow origin is close to the edges.(That's why when
arrow-rise is 0, it forms right angled corner).
So, a few condition checks are made to ensure that right angled corner
is not drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=699608
Right now we have three "dummy cursor" widgets between the background
menu, the message tray menu, and the IBus candidate popup. Consolidate
these into one "dummy cursor" widget which is tracked in the layout
manager.
Rather than GMenu / app-folder-categories. This removes our last use of
gnome-menus in the stock gnome-shell, which is exciting, but also means
that app folders in Software start working.
Ideally, we'd have a button to launch our Software app as well from the
overview.
https://bugzilla.gnome.org/show_bug.cgi?id=722117
Instead of having _compareItems, _getItemId, etc. on the view to
pull out info about items, use the AppIcon / FolderIcon items we
create as a place to track this additional info. We now require
that these items have a '.id' property for deduplication, and a
'.name' property to sort by.
https://bugzilla.gnome.org/show_bug.cgi?id=722117
Currently we only show/hide the left and right arrows when
we reach the initial/end position. This patch changes this
behaviour by showing the arrows whenever is a scroll is possible.
https://bugzilla.gnome.org/show_bug.cgi?id=711467
Right now we queue populating the user list in the middle of setting
up the dialog actors. Of course, the actual population happens some time
later after going back to the main loop.
It's more logical to structure the code so the the actors are
instantiated first in one block and then other things after that.
This commit moves the user list population enqueuing operation to the
bottom of the constuctor.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
In some cases we load the user list after going back
to main loop and in other cases we load the user list
right away (depending on if accounts service is ready).
In the case we load the user list right away we cause a
traceback because loading the user list forces a reset,
which then tries to reset actors which aren't instantiated
yet.
This commit ensures the user list is loaded after the constructor
finishes and the event loop runs irregardless of the accountsservice
state.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
One of the most frequent complaints about our launching behaviour is
how we handle terminals. Among all MDI applications, the terminal is
the one that is most likely to have lots of semi-independent windows
opened at the same time, and spawning new windows is much more common.
More so, if it does not support tabs.
Therefore, we special case terminal launchers to always create a new
window. It is an application that most non-technical users will not
use, so chances of them being confused by any special behaviour is
expected to be low.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Workspaces can removed from any index, and in particular they
will be removed by the WorkspaceTracker if they stop containing
windows at some point. Make sure WorkspacesView is not confused
and destroyes the right Workspace objects.
https://bugzilla.gnome.org/show_bug.cgi?id=721417
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712579
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712596
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712638
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712638
Filtering out "non-interesting" windows beforehand as we currently do
means that we may get properties that should be based on all windows,
like the last time the application was used, wrong.
Just track all windows and filter out non-interesting windows manually
in the one place we actually care about the difference.
https://bugzilla.gnome.org/show_bug.cgi?id=719824
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
Rather than implement special focus policies like only allowing keynav
when pressing down, simply give the active page key focus when entering
the overview.
This may break stuff, as it's somewhat of a tricky patch to get right.
Testing this one would be super appreciated.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
Simply use St's existing key navigation system by making all the window
clones StWidgets, and making the WorkspacesView a focus group.
Since the workspace view is effectively "fake", we need to add a focus
delegator so that when key focus is assigned to the fake workspaces page,
we can keynav inside it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
For mysterious reasons I'm not sure of myself, navigate_focus will only focus
mapped actors. So, make sure the widget is showing before navigating to it.
https://bugzilla.gnome.org/show_bug.cgi?id=709853
If the background is already removed, or we're trying to remove bad content,
this is probably a bug in content accounting, so let us crash so we can fix
the bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
Stomping on local variables and trying to keep loop state isn't
too fun. Just use a new variable here so we aren't too confused
with what we're doing.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
We don't have any better way of determining whether something is a slideshow
animation, so discriminate on the .xml filename instead of waiting for
gdk-pixbuf to determine whether it can load a file or not.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
The destroy vfunc might be called during object finalization, and
we can't call any JS from a GC finalizer, so we use a signal
connection instead, as that is removed by GObject the first time
the object is disposed.
https://bugzilla.gnome.org/show_bug.cgi?id=719730
After a user types in their password at the login screen, one
of two things can happen
1) a new session is started
2) an existing session is switched to
In the latter case, GDM sends a reset signal to the login screen,
so it knows to go back to the user list and wait to be summoned
again.
Unfortunately, all reset signals are ignored after verification
success. The reason is because the reset handler was copied from
the unlock dialog as part of a deduplication effort in commit
7e7295f259 and the unlock dialog
handler at the time also emitted a "failed" signal on reset
(which wouldn't make sense to emit after success).
These days "failed" is handled in a different way.
This commit changes the code to let reset signals through after
successful verification.
https://bugzilla.gnome.org/show_bug.cgi?id=710456
AppDisplay queues a deferred work to load frequently used apps when the
apps page is loaded. Unfortunately, when the overview is first opened,
all the pages start out visible and then immediately get hidden, so the
deferred work runs immediately after the first overview opening, whether
the user was going to view their frequent apps or not.
Start all pages off as hidden, and rearrange the code so that pages are
only shown when they really need to be.
https://bugzilla.gnome.org/show_bug.cgi?id=712753
This is also exposed in the ShowOSD DBus method, the "monitor"
parameter may contain an integer to indicate the monitor number.
If the value is not provided or <0 is used, the monitor is shown
on the primary monitor as usually.
This way, the OSD can be used to notify upon events that solely
apply to one monitor, like tablet mapping as discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=710373.
https://bugzilla.gnome.org/show_bug.cgi?id=712664
You would think we would already do something like this, but apparently
lots of code was calling hide() without checking if the box pointer was
already visible, causing it to queue a full tween. The biggest win was
with ibusCandidatePopup.js, which called hide() on every DBus message.
This increases the performance for me to enter the overview by a tiny
bit. The remaining time is spent updating the frequent apps / all apps
display.
https://bugzilla.gnome.org/show_bug.cgi?id=712727
The methods we call in _updateState may not be reentrant, so make
sure that we never get into a situation where _updateState, through
some crazy chain of events, calls itself.
https://bugzilla.gnome.org/show_bug.cgi?id=711694
Rather than scanning all apps for searching, use Ryan's new desktop
file index and the glib support APIs for app searching instead of our
own system.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
If monitor-changed fires at startup, it will destroy all of the
backgrounds, but since this._isStartup is true, won't recreate any
of them. Additionally, since _bgManagers is indexed by monitor index,
if the primary index is not 0, it could become a sparse array (e.g.
[undefined, undefined, primaryBackground]), and our for loop will
crash trying to access properties of undefined.
Fix both of these issues by always creating background managers for
every monitor, hiding them on startup but only showing them after
the startup animation is complete.
One thing we need to watch out for is that while LayoutManager is
constructing, Main.uiGroup / Main.layoutManager will be undefined,
so addBackgroundMenu will fail. Fix this by passing down the uiGroup
to the background menu code.
https://bugzilla.gnome.org/show_bug.cgi?id=709313
If desktop icons are enabled and not covered by maximized windows,
we will fade them in/out during overview transitions. However when
moving background handling into mutter/gnome-shell, we ended up with
the overview background on top of the DESKTOP window clone, hiding
the fade transition.
Fix the stack order to bring the effect back.
https://bugzilla.gnome.org/show_bug.cgi?id=707671
Our gnome-shell tweener integration has had hooks to determine when
the tweens have started and completed... except that they had a bug
in them. When a tween completed, it queued an idle handler to run
the callback in. If no tweens were running when the idle was removing,
it reset the tween state that contained the idle handler ID. It also
returned false, meaning that the source would always get removed.
If the actor had a tween in-flight when the idle was fired, it wouldn't
clean up after itself. While this is also a simple bug fix, remove the
callback so we don't queue unnecessary, unused idles.
https://bugzilla.gnome.org/show_bug.cgi?id=711732
Removing an existing source before scheduling a new one is not wrong,
but slightly less effective than doing nothing and relying on the
previously created source to do the job.
https://bugzilla.gnome.org/show_bug.cgi?id=711555
As the handler returns false, the corresponding source is removed
automatically and its id invalidated. Reset the id to 0 to reflect
this, otherwise newer versions of GLib will print a warning when
we later try to remove it explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=711555
There's a potential race condition in the search code: if we have an
outstanding search call to a provider for search "A", and if before it comes
back we do a subsearch for "AB", we won't have any results to pass along.
Previously, we used an empty list when storing the provider results, so we
effectively told the remote search app to filter through this empty list for
any search results that meet the new query, meaning we showed the user 0
results for the provider in this case.
Now that we don't store an empty list, but instead store `undefined`, this race
raises a warning. Solve it by doing an initial search query in this case
instead.
The search code isn't too smart about chained subsearches: now, if we hit this
race while already on a subsearch, we'll do an initial search for the subsearch
query instead, but that is much better than showing the user nothing. This
could be fixed in the future for a performance improvement.
Reviewed-by: Florian Müllner <fmuellner@gnome.org>
When a notification becomes expanded, it's either already shown,
or in the process of being shown. Don't set the state to SHOWING
again, which confuses our state machine.
The asynchronous nature of extension loading, session loading, and more,
makes the code racy as to what is initialized first, and hard to debug.
Additionally, since gjs is single-threaded, the only code we're running
in a thread anyway is readdir, which is going to be I/O bound, so the
code here is actually likely to be faster.
Drop this in favor of some good old fashioned synchronous loading.
We currently only ensure that width and height are positive, so it
is still possible to pass in values that don't make any sense at all
(which may even result in a crash when exceeding limits imposed by
X11).
There is nothing to screenshot outside the actual screen area, so
restrict the parameters to that.
https://bugzilla.gnome.org/show_bug.cgi?id=699752
We want to move away from gnome-menus eventually, so the simple
utility method isn't really worth keeping around. Reimplement it
in the one place that uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
Long ago, the search system worked in a synchronous manner: providers
were given a query, and results were collected in a single array of
[provider, results] pairs, and then the search display was updated
from that.
We introduced an asynchronous search system when we wanted to potentially
add a Zeitgeist search provider to the Shell in 3.2. For a while, search
providers were either async or sync, which worked by storing a dummy array
in the results, and adding a method for search providers to add results
later.
Later, we removed the search system entirely and ported the remaining
search providers to simply use the API to modify the empty array, but the
remains of the synchronous search system with its silly array still
lingered.
Finally, it's time to modernize. Promises^WCallbacks are the future.
Port the one remaining in-shell search engine (app search) to the new
callback based system, and simplify the remote search system in the
process.
`a + b ? c : d` is parsed as `(a + b) ? c : d`, not the more intuitive
`a + (b ? c : d)`.
This was causing a bad slide animation and Clutter warnings when coming
out of the overview.
The org.gnome.login-screen schema contains a key to disable the
power/restart buttons; our support for this fell victim to the
new combined status menu, add it back.
https://bugzilla.gnome.org/show_bug.cgi?id=711244
Before, workspacesOnlyOnPrimary was implemented in quite a crazy manner:
* If workspacesOnlyOnPrimary was false, we'd create one WorkspacesView per
monitor, with the primary one being a bit special.
* If workspacesOnlyOnPrimary was true, we'd create one WorkspacesView, and
additional montiors would be handled inside that WorkspacesView as
"extra workspaces".
This caused numerous bugs as the two modes weren't consistently
implemented, and a lot of code was duplicated between all the modes.
Fix this by always creating WorkspaceViews, even if it only handles
one interface. We do this by having two different WorkspacesView-ish
classes: WorkspacesView handles the traditional combination of lots
of workspces, and a new ExtraWorkspaceView is in control of only one
workspace.
Right now, the workspace update code is complex and spread across parts:
WorkspacesView takes a set of workspaces and looks like it owns them, but
WorkspacesDisplay is actually in charge of setting them up and creating
new ones for each WorkspacesView.
Change initialization and handling to move all of the creation/destruction
responsibilities to WorkspacesView.
We pass in monitorIndex into each WorkspacesView, which is a lie in the
workspacesOnlyOnPrimary case, as the primary WorkspacesView currently has
the responsibility of handling the extra workspaces on all the other
monitors. The commit will clean this up and punt the responsibility back
to WorkspacesDisplay.
Not because ClutterActor is bad or wrong, but because I always get
confused on the difference, and having them both in SlideLayout
makes the code a bit easier to read and understand.
The parent SlidingControl had an onOverviewShowing, but we had
overridden it with the same code in both subclasses. Just move it
back to SlidingControl.
