The code here before was added as dummy code to satisfy an error
in the missing switch, and wasn't ever tested due to the lack of XI2
in mutter. Use the same math as GtkRange does to calculate scroll bar
positions from raw XI2 deltas to allow for proper smooth scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
Instead of being fuzzy, the menu separators should be a clear
line with a horizontal gradient. This looks better and is
consistent with the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=641745
After the first time the title was placed, we were setting its width,
thus forcing get_preferred_width() to return that as the minimum and
natural width.
To workaround that, explicitly reset the width to -1, -1, causing
StLabel->get_preferred_width() to be called, which would give us a meaningful
value for minimum and natural width.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
WindowOverlay was at times seeing bogus values reported as WindowClone
sizes. Fix that by storing and passing the value from the authoritative
source, that is, the LayoutStrategy.
https://bugzilla.gnome.org/show_bug.cgi?id=688234
If present, InfiniBand devices show up with the ethernet devices (and
the presence of an InfiniBand connection will cause "Wired" to be
renamed to "Ethernet").
https://bugzilla.gnome.org/show_bug.cgi?id=677150
Both WorkspacesDisplay and ThumbnailsBox need to know when windows have been
restacked. Instead of each tracking changes on their own or trying to call
each other, have the overview keep track and do the calculations, emitting
a signal with the result.
https://bugzilla.gnome.org/show_bug.cgi?id=690175
meta_display_add_keybinding() returns a keybinding action ID for
dynamically registered keybindings which can be used to match a
keycode/mask pair to the action it is bound to.
https://bugzilla.gnome.org/show_bug.cgi?id=682315
Instead of storing them globally and having an hardcoded list of
engines which are allowed to change their indicator symbol when the
InputMode property changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682318
We previously scaled windows to (primary.x, 0), which is wrong if the
primary monitor is not at y == 0. At the same time, change the policy
to pick the hot corner on the monitor the window is on, because that's
closest to where it will appear in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
This makes the method usable in places where the associated window actor
might not have the right size (such as from window manager animations).
Also, make the method public from LayoutManager.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
If we overwrite a map animation (for example because the actor is now destroyed),
we need to complete it first, otherwise it starts off from a random
middle point. This is the same treatment opacity gets for normal windows.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
The thumbnail controls are not a separate actor in the overview group
yet, so we need to ensure a spacing between them and the workspaces
view.
Instead of exporting the overview spacing, just add a temporary style
class to the workspaces-view actor for it. It will be removed in the
future when we change the layout of overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=690174
realpath() does a series of lstat() on each path component to resolve
symbolic links, but we just want to get an absolute path, and we don't
really care if it is physical or not. Going through a GFile does the
canonicalization we need, and is a lot faster.
https://bugzilla.gnome.org/show_bug.cgi?id=687881
Adjust the layout of the overview and window thumbnails to make them
bigger. Also, make the background shade darker to compensate for the
increased thumbnail density.
https://bugzilla.gnome.org/show_bug.cgi?id=689876
Recreating icons on every style change -- like hover, can have
disasterous effects. Not only is the quick creation/destruction of
the actors bad, but adding/removing actors at runtime queues many
relayouts, which makes the whole system slower as a lot of unnecessary
reallocations are figured out.
While an optimization was here before, it was broken because it
broke high-contrast themes. Connect explicitly to the texture cache
to know when the icon theme has changed, instead of removing a valuable
optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=672941
