Devices like cameras and microphones are privacy sensitive, as they can
be used to spy on the user. We cannot prevent non-sandboxed apps from
doing that, but as we already track when the microphone is recording,
we can at least show an indicator to make sure it doesn't happen behind
the user's back.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/729
We are currently inconsistent whether to put the operators in front
of the corresponding line or at the end of the preceding one. The
most dominant style for now is to put condition and first branch on
the same line, and then align the second branch:
let foo = condition ? fooValue
: notFooValue;
Unfortunately that's a style that eslint doesn't support, so to account
for it, our legacy configuration currently plainly ignores all indentation
in conditionals.
In order to drop that exception and not let messed up indentation slip
through, change all ternary operators to the non-legacy style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
Commit 21e14bd46f fixed this for the
brightness slider, but we have the same problem for volume too. When the
volume is muted - for example in Settings or via a media key, we update
the slider to '0' to indicate this visually. But we also actually invoke
the slider's callback to *set* the volume to zero. That means that the
previous level is overwritten so it can't be restored when unmuting.
The fix is the same - when we update the slider internally ourselves,
don't call the signal handler.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1557
We have a couple of places where we don't tween the actor, but a
custom property on the delegate object. In order to move those
to Clutter animations, we will need an animatable, so turn those
objects into widget subclasses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/666
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
We can use that newer method where we don't care about the actual position
of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/152
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
Show an overamplified volume icon if volume is louder the max normalized one.
Use a similar logic as gnome-settings-daemon to delimit values, restricted
to output.
The purpose is to help users remember that visiting some websites or
using some apps can get LOUD.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
Depending on hardware and recorded volume level, turning up the speakers
to the maximum volume may not be enough and the user will want to amplify
the volume above 100%. Currently this requires opening the sound Settings
panel which gets cumbersome when required repeatedly.
To support this case better, allow raising the sound volume above 100%
directly from the system menu if the feature is enabled via the
`allow-volume-above-100-percent` key in `org.gnome.desktop.sound`.
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
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
It is possible to use the scroll wheel to adjust the volume without
opening the system menu, but there is no feedback other than the
icon itself in that case. To provide a less coarse indication for
the volume level, display the OSD window when adjusting the volume
while the slider isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=781028
There's only two uses of the parameter left, which can easily be added as a
separate line below. Since it's really a private interface meant for the
indicators, make it private as well so external users are less likely to
use it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
We can't silently replace the old behavior of separate status
icons into a new system. Replace SystemStatusButton with a new
SystemIndicator class which will allow for the flexibility we
need. For now, make it a subclass of Button so that it mostly
feels the same, but we'll soon be swapping it out with a dummy
implementation that the aggregate menu will use.
I think the code cleanup here is worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=705845
This is a regression from splitting the slider out that never got fixed.
Restore the previous (useful) behavior by adding a public API to the
slider that lets us pass an event through.
https://bugzilla.gnome.org/show_bug.cgi?id=704368
Calculate an icon based on our current state, not a mess of
signal emissions and callbacks. This is a preliminary basic
cleanup patch in preparation for the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=690539
Allow users to smoothly scroll on the volume indicator icon
to adjust the volume. Do this by simply passing the scroll
event to the slider inside the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
Currently the visibility of input volume is only updated when a stream
is added/removed - apparently no one noticed until now, as in the normal
user session we get away with this as long as we have some startup sound,
but this is not the case in the lock screen, so we may end up showing
input volume incorrectly.
https://bugzilla.gnome.org/show_bug.cgi?id=684611
