It was decided at GNOME Summit that we would remove the invisible
setting until we have a better story for how it works with chat
and other sharing/messaging applications. We'd also need to
figure out how it relates to busy.
The action is far less common than powering off. It is mostly
used for performing system updates so the update tool should
offer the option directly. Also, currently the Shut Down option
dialog offers Restart anyway. We would like to keep the number
of entries in this menu as limited (close to 7) as we can.
put a border around the "16px icon in 48px icon widget" test, to
verify that the icon is being centered correctly
add spacing and fix alignment for general prettiness
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Now that we're using St.Icon in the Javascript, there is no reason
to have separate st_texture_cache_load_icon_name() and
st_texture_cache_load_icon_name_for_theme(), instead just add
the StThemeNode argument to st_texture_cache_load_icon_name().
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Switch from St.TextureCache.load_named_icon() to using St.Icon for named
icons. Along with the advantage of getting colorization right for symbolic
icons, this allows moving some icon sizes into the CSS.
In the CSS, the system status icon size is changed to be 1em (=16px for the
default font size), at the request of the artists. See bug 613448.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Use st_texture_cache_load_icon_name_for_theme() so that we get the
right colors for symbolic icons. The code refactoring to achieve this
also avoids constantly starting a new icon load each time we set
a property on initialization ... the icon is loaded only after we
have a #StThemeNode assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Sometimes it's useful to get the theme node if there is one and do
nothing and wait for the ::style-changed signal if there is no theme
node. Add st_widget_peek_theme_node() that just gets the current
theme node if available. The caller must handle a %NULL return.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Add st_texture_cache_load_icon_name_for_theme() which, when loading a
symbolic icon, gets a #StIconColors from the theme node and uses that
to colorize the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
A new StIconColors object is used to efficiently track the colors
we need to colorize a symbolic icon.
st_theme_node_compute_icon_colors() is added to compute the
StIconColors for a theme node. (Refcounting of StIconColors means
that we'll typically share the colors object of the parent node.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Scaling up icons from the loaded size to a larger size is uniformly
ugly and results in a long series of "fuzzy icon" bugs. It's better
to just load at the specified size and center. (Centering can be
overridden by packing not-fill in the parent container.)
https://bugzilla.gnome.org/show_bug.cgi?id=633865
We don't want the layout to change when we say, change from
battery-full to battery-full-charging, so we should request a square
based on the icon size unconditionally and not try to adapt to the
size of the texture we loaded. This also means that our layout is
independent of the loaded texure which, if we switch away from
using a ClutterActor child will allow us not queue a relayout when
the icon finishes loading.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Make StIcon compile and work in St.
Changes:
* ::icon-type and st_icon_set_icon_type are added to allow
specifying SYMBOLIC/FULLCOLOR for an icon.
* Ability to set the icon name from the theme is removed; it
wouldn't easily fit into our framework and two levels of
abstraction between code and image doesn't seem that useful.
* size CSS property is renamed from x-st-icon-size to icon-size
to correspond to what we are doing elsewhere.
* CSS and property based icon sizing are cleanly layered - if
you set the icon-size property, the CSS size is ignored.
* Add a simple JS test of StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
StIconType will be used by a new StIcon class, so move it to the
header file of common enumerations. Including st-types.h which had
the St single-include check revealed that st-texture-cache.h didn't
have that check and several places were including that directly.
Fix that up.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
The ability to set a "content image" on an icon relies on the ability
to have custom theme properties of a "border image" (9-slice) type.
We don't have this, and the capability of a bordered image specified
by the theme can be achieved more naturally with standard CSS facilities.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
ST makes use of GTK+ for input methods and for icon themes; therefore
we have need to initialize GTK+ in order to test these parts of Clutter.
Instead of LD_PRELOADING our module, use a separately compiled executable
that links to the UI components in GNOME Shell, initializes Clutter and
GTK+ and hooks them together.
Getting all the symbols from St and the GUI components exported for
use via GJS requires a bit of contortion: we need to actually link the
St convenience library into a shared library and link the executable
to that since there is no way with libtool to take a convenience library
and put all its symbols into an executable --whole-archive style.
https://bugzilla.gnome.org/show_bug.cgi?id=633657
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
gnome-settings-daemon has moved to GSettings for most settings, we
should adapt as well. The only remaining GConf key is for metacity
(visual bell).
https://bugzilla.gnome.org/show_bug.cgi?id=634693
We weren't properly nulling out the vadjustment variable in dispose()
which meant in the case of explicit-destroy followed some time later
by garbage collection and disposing the actor again we would crash.
Waiting for LookingGlass to close after calling St.set_slow_down_factor()
is annoying so divide the time for opening and closing by the slow-down
factor.
Use StWidget:track-hover rather than doing it ourselves. Don't assume
that hover is always TRUE after an enter_event or FALSE after a
leave_event, since we have a pointer grab and will be getting other
actors' events.
Don't ungrab the pointer when it leaves the button, since that
destroys the whole point of getting a grab in the first place.
Only consider the button to have been clicked when it has both grab
(meaning the mouse was pressed over the button) and hover (meaning the
mouse was released over the button).
Also remove the virtual pressed/released methods, which weren't being
used anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=633853
As popup menus now take focus for keyboard navigation, no application
is focused when activating the menu. Use the target application instead,
which keeps track of the application currently associated with the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=634103
Action names sometimes unintentionally overlap with icon names, so
we should only create icon buttons if the message tray source requests
it. For the notification daemon, this is done by setting the
'action-icons' hint on the notification.
The previous notification server capability used to advertise this
feature, "x-gnome-icon-buttons", has been removed in favour of the
new capability described in the notification spec, "action-icons".
https://bugzilla.gnome.org/show_bug.cgi?id=624584
The volume status icon requires libcanberra; we could get by with
packages so far, but we will need a very very recent libcanberra soon
anyway, so just require that.
https://bugzilla.gnome.org/show_bug.cgi?id=633418
Like all X API, XFixesGetCursorImage returns arrays of 32-bit
quantities as arrays of long; on 64-bit systems we need to
convert to an array of 32-bit words before creating a texture
from the result.
https://bugzilla.gnome.org/show_bug.cgi?id=633591
