The current design features a sidebar where the icon size shrinks
automatically to fit more items. Add a setSizeManually parameter
to BaseIcon, which disables sizes read from CSS and allows to use
BaseIcon.setIconSize() to support this.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
All mockups now use a representation for documents/places similar to
the one used for applications. Rename AppIcon to BaseIcon and move its
code together with WellGrid out of appDisplay to stress their general
usefulness.
https://bugzilla.gnome.org/show_bug.cgi?id=625887
Switch to using the layer combine constant rather than the material
primary color for representing the opacity of the material; this
avoids triggering a Cogl bug where changing the primary color corrupts
the layer state.
https://bugzilla.gnome.org/show_bug.cgi?id=629616
The actor emitted by ShellTrayManager is now ShellTrayIcon, a subclass
of ShellGtkEmbed which has several properties on it which are (or will
soon be) useful to the shell.
Part of the rearranging to use ShellTrayIcon means that we now show
the ShellEmbeddedWindow before creating its ShellGtkEmbed, which
requires a few modifications to ShellEmbeddedWindow (notably, telling
it at construct time what stage it will be drawn on, since it needs to
know that before it has a ShellGtkEmbed now).
https://bugzilla.gnome.org/show_bug.cgi?id=608869
Previously the code to keep the X window aligned with its actor made
various assumptions that were true in the panel status tray area but
that are not true in the message tray. Fix it up by repositioning the
X window at clutter_actor_paint() time, which will definitely be
called every time the actor moves, whether it's because of its own or
its parent/ancestor's changes.
https://bugzilla.gnome.org/show_bug.cgi?id=608869
As of 1.4, ClutterGLXTexturePixmap is identical to
ClutterX11TexturePixmap (with the differences having been moved into
the cogl layer). So make ShellGtkEmbed use the (introspected) X11
version, which then allows us to make the instance and class structs
public as well.
https://bugzilla.gnome.org/show_bug.cgi?id=608869
Resolve a notification's ShellApp before posting the notification, so
that notification sources now always have an app associated (assuming
they came from an app as opposed to the command line). Index sources
by PID rather than by appName (so that, eg, multiple calls to
notify-send now show up as separate sources).
For Sources that have an associated app, use the app's icon for the
source, rather than tracking the notification icon.
This change also lets us get rid of appNameMap, since we can just use
shell_app_get_name() now.
https://bugzilla.gnome.org/show_bug.cgi?id=629090
Previously we were hiding the banner label if the title was too long,
but this causes queue_relayout() warnings. Instead, just set its
opacity to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=629308
GConf requires it to build, it's been forgotten when we introduced
it into the moduleset. Debian uses 'liborbit2-dev', Fedora
and Mandriva 'ORBit2-devel', and SuSE 'orbit2-devel'.
https://bugzilla.gnome.org/show_bug.cgi?id=629882
Introduce the Universal Access status indicator as designed, modeled
after the similar UI provided by g-s-d. This indicator allows the user
to change rapidly the keyboard and mouse behaviour (sticky keys, slow
keys, bounce keys, mouse keys), as well as the enabled ATs (magnifier,
screen reader, screen keyboard) and the HighContrast Gtk theme.
https://bugzilla.gnome.org/show_bug.cgi?id=624916
Adds class PopupSubMenuMenuItem, which is an item holding a submenu,
that is opened when the corresponding item is active, and is keyboard
and mouse navigable like its Gtk counterpart.
https://bugzilla.gnome.org/show_bug.cgi?id=623498
This patch allows the icon in PopupImageMenuItems to be changed at
any time, while preserving the item and all other properties (style,
signals) attached and without rebuilding the whole menu. This is useful
for images reflecting a dynamic status (e.g. cellular strength
indicator or battery level)
https://bugzilla.gnome.org/show_bug.cgi?id=623652
Modal dialogs slide back into the titlebar of the parent window when destroyed.
This looks weird if the parent window itself has been destroyed, so cancel the
effect in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=629560
Extend WellGrid with an optional rowLimit parameter and an accessor
function for the grid's items, then use it to replace the custom
container used to display the application search results.
Also adjust the spacing of the search results slightly to make it
consistent with the app well.
https://bugzilla.gnome.org/show_bug.cgi?id=622446
The shader currently forces GLSL 1.0 to avoid being incompatible with older hardware but is still using features not available in 1.0.
Strict compilers fail to compile the shader:
error C7506: OpenGL/ES does not define the global variable gl_TexCoord
As every hardware/driver that supports 1.0 also supports 1.10 bumping the version to fix it is safe.
https://bugzilla.gnome.org/show_bug.cgi?id=629343
The keyReleaseEvent handler does not take into account that a
user might release Alt while still holding shift
(the keycode becomes Meta_L/R in that case).
The result is that the switcher stays open which is unexpected.
https://bugzilla.gnome.org/show_bug.cgi?id=629368
Override the new mutter preference /apps/mutter/general/attach_modal_dialogs
to attach modal dialogs to their parent window. Animate the modal dialogs
expanding from the top of the parent window. Slowly dim the parent window
after the dialog comes up.
https://bugzilla.gnome.org/show_bug.cgi?id=612726
This patch ensures the following notifications behavior:
- Urgent notifications that have long title or banner text are auto-expanded
correctly.
- Single-line notifications that have _expandNotification() called (e.g.
because the user mouses over to them), are treated as expanded, which means
they get fully expanded if they are updated with more content and the user
can escape them.
- The position of expanded notifications is updated when they are updated.
- Notification banner is shown again on the first line if it can fully fit
there after a notification is updated, even if it was previously hidden
because the notification was expanded and the old banner did not fully fit.
- New notifications are immediately hidden if the user mouses away from them.
- If a new notification is updated while it is shown, we extend the time it
will be shown.
- If a new notification is updated while it is hiding, we stop hiding it and
show it again.
- If a summary notification is updated while it is hiding, we let it finish
hiding and show a new notification with the updated information.
Implementation details:
- Single-line notifications now have 4px bottom padding instead of 8px, which
means that their height matches the tray height, they are fully shown in the
banner mode, and don't pop out by 4px when the notification is expanded.
- Notification keeps a flag that indicates whether it is expanded, updates
its expanded look when it is updated, and emits an 'expanded' signal
indicating that its layout has possibly changed. The message tray connects
to this 'expanded' signal when it is showing a notification in the expanded
state and updates the position of the notification accordingly when this
signal is received so that the notification is fully shown. This is better
than connecting to 'notify::height' signal on the notification bin, since
it results in fewer callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=617209
The Shell is the only user of the magnifier, so there's no
reason to keep using GConf for its settings. Since it's a
session-wide tool, use a distinct schema,
org.gnome.accessibility.magnifier, stored in
/desktop/gnome/accessibility/magnifier just like before.
Put these settings in a separate schema file for clarity.
Old enums in GConf were stored as integers, we now use the
facilities provided by GSettings to save them as strings,
and convert them to integers automatically thanks to the
mapping stored in the schemas. Remove hard-coded default values,
which we can get from the schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=622414
