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.
When we create a result actor, cache it, so it can be used for
subsearches of the same initial. For now, to keep memory usage
and the stage graph relatively clean, don't persist the actors
across searches, but maybe we should do this in the future.
This also means that we don't query getResultMetas for items
that we've seen in the same initial search.
https://bugzilla.gnome.org/show_bug.cgi?id=704912
The existing provider system is split between a confusing mess of
RemoteSearch, SearchSystem, SearchDisplay, and ViewSelector, partly
because of the vestigal in-shell search system. Move most of the
logic to search.js so it's easier to read.
We fetch and store the list of providers from the search system when we
construct SearchResults, but we never update this list when providers are
changed at runtime, causing various bugs making the search not seem as
snappy as it should be. Make sure to always fetch the list of providers
from the search system.
While the existing comment is correct in that a source's notifications
will be destroyed first, the code takes a shortcut which prevents the
Source::count-updated signal from being emitted. Given that the purpose
of the signal is to keep notification counters up-to-date which is
pointless when the source is about to be destroyed, the shortcut makes
sense; just save notifications explicitly in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=710596
search.js used to do a lot more, but now that most of the
functionality has been moved to the remote search system,
it doesn't do a lot. Merge searchDisplay.js into it.
It's been broken for quite a bit since we removed Panel.Animation,
and hasn't really ever worked with our new search results. It's also
the only non-remote provider left.
Maybe we'll add it back as a remote provider later, but for now, just
ditch it.
The new API is designed to support features like persistence and uses
the new org.freedesktop.Application specification for activating
actions on notifications. While we won't add support for persistence
yet, implement the new notification spec with parity of the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Their use blocks activation of the default button by keyboard, which
is important for accessibility. Use a Clutter.ClickAction instead,
which doesn't have this problem as it only considers mouse events.
https://bugzilla.gnome.org/show_bug.cgi?id=710144
Otherwise, when closing the tray, we'll try to focus an actor, which will
focus the stage window, which will drop the focus from whatever window we
already had focused.
https://bugzilla.gnome.org/show_bug.cgi?id=710347
The application picker will always open with the view that was last
selected during the session, but the selection is reset on each
restart. This results in some annoyance for users that use the
ALL view exclusively, as they have to toggle views once each
session - the same would apply to exclusive FREQUENT view users
were the defaults to be changed, so the best solution is to simply
make the selected view persistent by storing it in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=710042
If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
oVirt is software for managing medium-to-large scale deployments of
virtual machine guests across multiple hosts. It supports a feature
where users can authenticate with a central server and get
transparently connected to a guest system and then automatically get logged
into that guest to an associated user session.
Guests using old versions of GDM support this single-sign-on capability
by means of a greeter plugin, using the old greeter's extension
API.
This commit adds similar support to the gnome-shell based login screen.
How it works:
* The OVirtCredentialsManager singleton listens for
'org.ovirt.vdsm.Credentials.UserAuthenticated'
D-Bus signal on the system bus from the
'org.ovirt.vdsm.Credentials'
bus name. The service that provides that bus name is called
the oVirt guest agent. It is also responsible for interacting
with the the central server to get user credentials.
* This UserAuthenticated signal passes, as a parameter, the a token
which needs to be passed through to the PAM service that is specifically
set up to integrate with the oVirt authentication architecture.
The singleton object keeps the token internally so it can be queried
later on.
* The OVirtCredentialsManager emits a signal 'user-authenticated' on
it's object once the dbus signal is triggered
* When the 'user-authenticated' signal is emitted, the login screen
tells GDM to start user verification using the PAM service. The
authentication stack of the service includes a PAM module
provided by oVirt that securely retrieves user credentials
from the oVirt guest agent. The PAM module then forwards those
credentials on to other modules in the stack so, e.g.,
the user's gnome keyring can be automatically unlocked.
* In case of the screen shield being visible, it also will react on that
'user-authenticated' signal and lift the shield.
In that case the login screen will check on construction time if
the signal has already been triggered, and a token is available.
If a token is available it will immediately trigger the functionality
as described above.
Signed-off-by: Vinzenz Feenstra <evilissimo@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=702162
Allow the prefix 'special:' applied to result IDs to mark results
that should be always shown, even when they would overflow the
maximum results cap. This will be used by epiphany for the special
"Search the Web" result.
https://bugzilla.gnome.org/show_bug.cgi?id=707055
NotificationDaemon doesn't pass a gicon to the Notification constructor,
because it calls .update() immediately after, so messageTray.js
calls into Source.createIcon(), which returns null and crashes.
Instead, shortcut the Notification constructor by skipping
.update() completely.
https://bugzilla.gnome.org/show_bug.cgi?id=709998
The _background hack was added because the old way the zooming animation
worked, it set the allocation of the workspaces view and thumbnails box
to the final position and used animations to smoothly animate.
During the 3.6 cycle when we added the new search view, Cosimo changed the
way the zoom animation works so that rather than set the final allocation
and animate, we actually do adjust the allocation of the workspaces view
and thumbnails box.
So, as the hack is no longer necessary, we can drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
In order for the workspace thumbnails box to have the correct size,
we need to constrain the width of the thumbnails box to the height we're
given, instead of assuming an unlimited height.
https://bugzilla.gnome.org/show_bug.cgi?id=694881
We cannot wait for the queued update region to fire when
xdnd is being used because a wrong input shape can result
into a xdnd leave event when the user moves the pointer fast.
https://bugzilla.gnome.org/show_bug.cgi?id=708887
Since the agregate menu does 120% of font-size, make this
for all dropdown arrows in gnome-shell and rename the css
class to make clear that it is used in overall gnome-shell
https://bugzilla.gnome.org/show_bug.cgi?id=709564
According to the designs, the notifications switch was supposed
to move from the user menu to the new message tray menu. However
so far the new system status implementation only removed the old
switch, so add it back in its new place now.
https://bugzilla.gnome.org/show_bug.cgi?id=707073
Because of the animation and collision with relayout, the title of windows in overview may not appear, mainly
the first time we enter in overview
With an animation delay of 0.1s, you'll not see the difference
https://bugzilla.gnome.org/show_bug.cgi?id=709392
Show "Hardware Disabled" when disabled by HW switch, and
generically "Disabled" when airplane mode is active, as
indicated by v4 mockups.
Note that bluetooth is not affected by NM handling of airplane
mode (and generally the firmware makes the USB bluetooth
adapter disappear when rfkilled), so this is in NMDeviceModem
instead of NMConnectionDevice.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
Since commit 1242a16265, we will use a fake prompt which
cancels alls requests without dialog when the keyring component
is disabled. However this does only apply to new requests, dialogs
that are already active when the session mode changes are kept
open. This is not quite as expected, so cancel the prompt in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=708910
The property is on the NMClient, not NMDevice. Also, make sure
we disconnect the signal when the item is destroyed.
Also, connect to wireless-hardware-enabled, which we'll use soon.
https://bugzilla.gnome.org/show_bug.cgi?id=709635
Destroying the notification will make the key focus be reset to NULL, which
means that gnome-shell will try to focus the MRU window, thinking the user is
done interacting and wants to go back to whatever they were doing.
Unfortunately, since we focus two windows at the same time, they will have
the same timestamp, meaning that the window that actually gets focused will
be a race as to whoever responds to their WM_TAKE_FOCUS event last.
If we explicitly set the focus beforehand, then gnome-shell will believe it
got key focus taken away from it, and won't try to focus the MRU when the
key focus drops to NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=703265
We must reduce the forWidth in the call to get_preferred_height()
with the border width, otherwise we might request a smaller height
that we actually need and overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=696564
If the active connection for the device is not the primary or
activating globally, it won't have the _connection and _primaryDevice
expando properties, so grab them from the settings object.
https://bugzilla.gnome.org/show_bug.cgi?id=709043
The patch fixes the following warning, and along with it, the proper
destruction of the NMConnectionSection is performed so that items get
correctly removed from the menu.
(gnome-shell:24528): Gjs-WARNING **: JS ERROR: TypeError:
this.statusItem is undefined
NMConnectionSection<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:173
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMConnectionDevice<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:292
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
_parent@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:175
NMDeviceModem<.destroy@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:448
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._removeDeviceWrapper@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1421
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
NMApplet<._deviceRemoved@/home/aleksander/gnome/install/share/gnome-shell/js/ui/status/network.js:1416
wrapper@/home/aleksander/gnome/install/share/gjs-1.0/lang.js:213
https://bugzilla.gnome.org/show_bug.cgi?id=709248
Don't assume that this._bgManagers.push() (i.e adding to the end) is always
correct.
On startup we call _createPrimaryBackground which passes in the primary index
which may not be 0.
We connect to the changed signal in _init() but never actually disconnect from
it. The callback has a reference to "this" which results into the background
object not getting garbage collected.
Fix that leaks by disconnecting in _destroy()
https://bugzilla.gnome.org/show_bug.cgi?id=709263
