Although within St itself there are situations where the semantics of
these functions (return TRUE or FALSE and return the actual value in
an out parameter) is useful, it's mostly just annoying at the
application level, where you generally know that the CSS property is
going to specified, and there is no especially sane fallback if it's
not.
So rename the current methods to lookup_color, lookup_double, and
lookup_length, and add new get_color, get_double, and get_length
methods that don't take an "inherit" parameter, and return their
values directly. (Well, except for get_color, due to the lack of (out
caller-allocates) in gjs.)
And update the code to use either the old or new methods as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=632590
Gjs changed to separate the "basic" API from "embedder" API. Unfortunately
due to our use of the importer API and a few other bits, we need to use
the "module" one. In the future I plan to extend the core API to
support this use case.
Add volume control indicator which uses API from gnome-volume-control
to interact with PulseAudio and shows both input and output volumes.
Also adds a small wrapper around libcanberra in ShellGlobal, used by the
volume indicator to provide auditive feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=629455
Shell implemented indicators got padding from default button style,
and also spacing from their container, so too much space was left
between them. This only became apparent when more than one was
implemented, though.
The library is introspected, and should not require using
Pulseaudio directly.
With help from Giovanni Campagna <scampa.giovanni@gmail.com>
(introspection annotations, build fixes)
https://bugzilla.gnome.org/show_bug.cgi?id=629455
st-theme stores some loaded stylesheets in a custom
stylesheets list. When removing items from this list
it unrefs them, but when adding items to the list it
neglects to ref them. This means that under certain
circumstances the list will contain items that have
already been freed.
https://bugzilla.gnome.org/show_bug.cgi?id=632477
Right now if XDG_DATA_DIRS is set to have duplicate entries,
then the extension system will try to load all extensions
more than once.
This commit prevents an extension from getting repeatedly
loaded by checking if its uuid is already registered.
https://bugzilla.gnome.org/show_bug.cgi?id=632477
StDrawingArea uses the member variable needs_repaint to keep track
of whether it needs repainting. The variable is set to TRUE correctly,
e.g. on allocation or style changes - alas, it is never set to FALSE,
resulting in the area being repainted continuously.
https://bugzilla.gnome.org/show_bug.cgi?id=632197
Since we're just using a cut-and-paste of gdm code there's a
slight impedance mismatch between how that code and the rest of
the shell manage debug messages. In GDM, they're out of sight by
default, but in gnome-shell they're visible and quite verbose.
This muddies up and masks the useful messages that other parts
of the code generate.
This commit just mutes the messages unconditionally by default,
since they aren't that useful anyway.
The GDM code upstream talks to the account service now,
has better introspection annotations, and is more
asynchronous.
This commit updates the shell's copy to the latest
upstream.
Note, the API changed somewhat and so the callers will
need to be fixed up subsequently.
https://bugzilla.gnome.org/show_bug.cgi?id=631888
Tray icons control their own lifespan; they're not supposed to
disappear when you dismiss their notifications like non-trayicon
notification sources do.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Previously, when you clicked on a notification, it would call
this.source.clicked(), which would emit a 'clicked' signal on the
source, and then various other stuff would happen from there. This
used to make a little bit of sense, when clicking on a notification
was supposed to do the same thing as clicking on its source, but makes
less sense now, when clicking on the source itself *doesn't* call
source.clicked()...
Change it so that when you click on a notification, the notification
emits 'clicked' itself, and the source notices that and calls its
notificationClicked() method, and the various source subclasses do
what they need to do with that, and Source no longer has a clicked
method/signal.
https://bugzilla.gnome.org/show_bug.cgi?id=631042
Redo the way that the summary item expand/collapse animation works so
that the items all resize in unison so that when moving from one to
another, the summary area as a whole stays a constant width rather
than wobbling slightly.
(Also rename all references to the "minimum" summary item title width,
since it's not a minimum, it's just the width.)
https://bugzilla.gnome.org/show_bug.cgi?id=630546
This fixes the bug when the body would be missing from the expanded notification
that has a short body that used to fit in the one-line banner and is expandable
because it has action buttons.
We always want to add the banner to the body of an expandable notification,
unless the notification has custom content. We used to only do that when
creating this._scrollArea for the content. We should also do that when creating
this._actionArea .
https://bugzilla.gnome.org/show_bug.cgi?id=631566
1. move logic to shell-app.c
2. change state to RUNNING only after startup sequence complete
3. correct handle state for applications with several .desktop files
https://bugzilla.gnome.org/show_bug.cgi?id=623688
It's possible that an item that was added to the summary got removed before
we had a chance to show the summary because the user has interacted with
the notification (e.g. clicked on an application ready notification). We should
not be showing the summary with an unchanged set of items in this case.
However, it is possible that multiple items were added to the summary before
we had a chance to show the summary, and only some of them got removed. In view
of this scenario, we can't just use a boolean flag to indicate if the summary
needs to be shown, but have to maintain an array of new summary items instead.
https://bugzilla.gnome.org/show_bug.cgi?id=630939
