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
We shouldn't hide the tray as quickly if the user might have left it
unintentionally, such as when moving the mouse over to a different tray item or
using the scroll bar in the chat notification.
https://bugzilla.gnome.org/show_bug.cgi?id=630767
This way the new modal level is independent of whatever may have been
happening before. Fixes a problem with status menus becoming active
again from inside the app switcher, etc.
Tray icons replaced by a shell version are automatically filtered
and never make to the tray container, but when removed by the client
we were still trying to remove them from the tray, causing a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=633028
Each menu is a focus manager group, but there is also some explicit
focus handling between non-hierarchically-related widgets. Eg, to move
between menus, or from a menubutton into its menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
Add StWidget:can-focus, st_widget_navigate_focus(), and
st_container_get_focus_chain(), and implement as needed to allow
keyboard navigation of widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
In d66e7dd49 I got confused between border_texture and
background_texture. The background_texture was being created as normal
but in the one place that it gets drawn I accidentally made it use the
border_material instead. This patch makes it create a
background_material similar to the border_material and uses it to
paint.
A few places in st-theme-node-drawing create one-shot material, paint
with it and then free it. This is suboptimal with current Cogl because
it will end up compiling an ARBfp program just for that single paint
and then it will throw it away when the material is destroyed.
There is a new function in st-private.c called
_st_create_texture_material. This creates a simple material for a
texture based on a common parent material that points to a dummy
texture. Any materials created with this function are likely to be
able to share the same program unless the material is further modified
to contain a different number of layers. It would be possible to use
cogl_set_source_texture for this instead except that it's not possible
to modify the material's color in that case so we couldn't render the
texture with opacity.
The corner textures are now stored as a handle to a material that
references the texture rather than storing the texure directly. There
is also a separate border_material member which always points to
border_texture as the only layer.
https://bugzilla.gnome.org/show_bug.cgi?id=633340
The constructor was setting this.active to reflect the switch state,
which is wrong; this.active indicates whether or not the item is
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=621671
Adding a "PopupMenuRadioButtonItem" wouldn't work well, because we'll
need radio-button indicators on multiple different styles of menu
item. Also, the current design draws the indicator in the menu item's
padding, so it's sort of special anyway. So just add support at the
BaseMenuItem level.
Also, redo the menu/menuitem padding so that all the horizontal
padding is in the menu item, or else the indicator dot will show up in
the wrong spot.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
When there are menu items with right-aligned items, all the
right-aligned items should appear to the right of all the left-aligned
items.
Clutter doesn't have an equivalent of GtkSizeGroup, so hack something up
using ShellGenericContainer and some javascript.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
Rename a few, and add Suspend and Restart, although currently they do
the same thing as Shut Down (ie, they bring up a dialog that lets you
do any of those three). This will be fixed later when we have the
in-shell modal dialogs for these features.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
In the new mockups, the user menu icons are on the right, not the
left.
Also, get rid of the idea of optional icons; the design doesn't have
icons on those items, and there probably aren't going to be symbolic
versions of some of those icons anyway. So if the caller specifies
PopupImageMenuItem, then always show an icon, and just use regular
PopupMenuItems for the items that don't have icons in the current
design.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
