As a mount operation's UI may be reused (for example after mistyping
the password), we only close the operation once the mount has finished
(successfully or with error).
We therefore need to track ongoing operations, which we currently do
by monkey-patching the corresponding volume object. However while the
underlying GVolume object indeed remains the same through-out the
operation, the JS wrapper object isn't referenced anywhere and may
thus be garbage collected, resulting in a stuck dialog.
Fix this issue by tracking active operations explicitly, so that all
involved objects are referenced until the end of the operation.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/565
The `hints` and `settingName` parameters to the agent call may define
the specific list of secrets NM actually needs from the user. This
seems to have been the intended use of these two parameters but only
recently did NM with the IWD backend start to use this to request 802.1x
secrets. So if `hints` is provided, ask user for the specific secrets
listed there and don't even look at what type of EAP method is in use.
Only the three types of secrets actually in use by NM's IWD backend are
supported for now -- they happen to be the same three that
_get8021xSecrets() had already supported.
If the volume is removed before AUTORUN_EXPIRE_TIMEOUT_SECS seconds, we can stop
the timeout earlier as there's nothing to unset, while the volume instance
won't be valid anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
Since commit 78a92fb6be we no longer pop up authentication dialogs
on the lock screen, however any dialog that is already open at that
time remains open. This is unexpected, so hide the dialog until
the screen is unlocked again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/166
While polkit requests *should* be the result of a user action, that's
not always the case in practice and authentication dialogs can pop up
out of nowhere at any time. That's always annoying, but particularly
bad on the lock screen. If we disabled the polkit component altogether,
the fallback GTK-based agent would kick in, so instead handle the case
explicitly and postpone showing the dialog until the session is unlocked.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/179
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
When the agent doesn't work (e.g. when the screen is locked), it shouldn't be
registered with NM. Otherwise it will keep cancelling the requests that
could happily be serviced with system secrets.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
The native agent already forgets about the request at the point it's
serviced and the further attempt to use it (e.g. cancel it when the screen
is locked) will trigger an assertion failure:
** (gnome-shell:30862): CRITICAL **: shell_network_agent_respond: assertion 'request != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=789811
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Commit 39a840e2c3 added an additional parameter to shell_app_launch().
When adjusting callers, the parameter was also added accidentally to
calls of the confusingly similar g_app_info_launch() ...
Remove those to fix some warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Telepathy's role has been diminishing continuously over the last
couple of years, so while chat integration is a nice feature for
those who use it, it is hard to justify keeping it as a hard
dependency. To address this, split out the component from the
client so we can handle missing typelibs gracefully by not
providing any chat integration.
https://bugzilla.gnome.org/show_bug.cgi?id=779878
The telepathy integration was written at a time where gjs didn't
allow to inherit from GObject classes, which is why we needed a
C helper class. This hasn't been the case for a while now, so cut
out the middle man and implement Tp.BaseClient directly.
https://bugzilla.gnome.org/show_bug.cgi?id=771721
Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
Currently the cache is built once when the first VPN request is
handled, so plugins that are installed or uninstalled after that
aren't picked up. Fix this by invalidating the cache on changes
to the plugin directory.
https://bugzilla.gnome.org/show_bug.cgi?id=773893
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
Since commit 82950ecea, we acknowledge pending messages when closing a
chat notification for a channel we are handling to prevent the channel
from popping up again immediately. While this isn't an issue for channels
we don't handle, the unread messages of the destroyed notification are
still considered for the messages indicator in the top bar, which is
clearly confusing (in particular when we end up showing the indicator
without any notifications in the list). As it's arguably correct to not
meddle with a channel handled by someone else, just reset the cache of
pending messages to address this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=770888
While a channel has pending messages, it will pop up again when
dismissed. That is clearly not what users expect, so clear them
out first before closing a channel.
https://bugzilla.gnome.org/show_bug.cgi?id=747991
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Builtin chat and network notifications already follow the notification
policy of appropriate applications, it makes sense to do the same for
autorun notifications to give users control over hotplug notifications
in Settings.
There is nothing particularly critical about this notification, it
was only marked as such to get certain behavior like auto-expanding
and sticking-around to be acknowledged by the user (as it offers
more actions than the summary notification, so it is frustrating
when it goes away because it was missed).
As all notifications will now stay visible until we are sure the
users has seen them, the latter reasoning no longer applies.
Auto-expansion doesn't appear too important and may even be considered
annoying by users, so remove the CRITICAL hint now.
https://bugzilla.gnome.org/show_bug.cgi?id=657923
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
Sources are destroyed with their last notification. This is usually the
correct behavior, however in case of chat sources, the corresponding
telepathy channel might still be open, and any further messages that
should trigger a notification are lost because chat sources are only
created when telepathy's channel dispatcher notifies us about a channel
(via ObserveChannels).
Loosing messages like this is unexpected, so keep chat sources around
even without notifications while the channel is open.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
Currently the lifetime of a chat source and its single notification
are tied together. While this apparently makes sense, it means we
will lose all follow-up notifications when a source is destroyed
with the corresponding telepathy channel left open. We will fix this
soon by tying the source to the channel's lifetime rather than the
notification, prepare for this by recreating the notification if
necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=747636
When the chat app is focused, we should hide all banners immediately.
A good way to do so, without tracking which app is focused, is
to look for messages that are acked when the banner is unexpanded,
which implies they were acked by some other telepathy client.
https://bugzilla.gnome.org/show_bug.cgi?id=746364
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=660293
There's a strong expectation that delegating or presenting a channel
will result in a window being activated, so close both overview and
calendar as we do elsewhere.
Replace the time formatting in notifications and events with the
new utility method - this makes sure that all times are now following
the clock-format setting and use LC_TIME.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
These notifications are annoying for the most part: presence
changes happen inside an app (empathy or polari), and that app
should have in app notifications for errors, instead of spamming
the global notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=745503
polari is the GNOME app for IRC, empathy is for everything else
So prefer polari to empathy for IRC channels. We don't need
to check that either exists (even though polari is not a core
app) because mission control tries every handler if the preferred
one fails.
Depends on bug 745418 for polari to be mission control activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=745431
Chat notifications are king of custom, so we'll leave them out for now
and keep using the old banner. However we can port the subscription
notification.
Hotplug notifications use custom notification banners to include
application icons in buttons. Bring those back by providing an
appropriate createBanner() implementation.
Nothing except for the chat notification is really custom, so stop
specifying the flag for anything else - it will soon become a bit
harder to create non-standard notifications, so don't do it for no
good reason (discouraging this is of course the reason for making it
harder in the first place) ...
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
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
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
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
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 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
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
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
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
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
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
