Our usage of DamageReportBoundingBox was causing us to miss some
updates when an area of the screen was drawn twice in rapid
succession. Add an explicit XSync() call to force the server
to flush rendering to the kernel before we draw.
https://bugzilla.gnome.org/show_bug.cgi?id=657071
If XRANDR is availible, we track the first (or primary) output per
crtc (== xinerama monitor) so when the monitors change we can try
to find the same output and move windows there. If we can't find the
original monitor in the new set (or XRANDR is not supported) we move
the window to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=645408
The ignored_serials member of Display refers explicitly to crossing
serials - rename the member and associated functions and constants
for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=597190
* Export meta_display_add_ignored_crossing_serial()
* Add the serial for reshaping the stage
* Increase the size of the "ignored_serials" array a bit to
try to avoid the possibility of losing serials from multiple
reshapes happening close together.
https://bugzilla.gnome.org/show_bug.cgi?id=597190
This goes better with the general style of similar alerts throughout
GNOME 3, and as has been pointed out in bug 591735, 'Mutter' is
a somewhat unfortunate title in several lanuages, such as English
and German.
* At least one line (possibly blank) is required after a function name for a doc header
to be parsed correctly.
* SnStartupSequence isn't a type known to introspection
Some apps that do a lot of rendering on the screen like games, mostly run in
fullscreen where there is no need for them to be redirected doing so does add
an overhead; while performance is critical for those apps.
This can be disabled / enabled at runtime using
meta_enable_unredirect_for_screen / meta_disable_unredirect_for_screen
https://bugzilla.gnome.org/show_bug.cgi?id=597014
Instead of requiring a singleton MetaBackgroundActor for the screen,
allow creating multiple copies that internally share a single
CoglTexture behind the scenes. This will be useful for allowing
multiple views of the screen background with different rendering
options.
https://bugzilla.gnome.org/show_bug.cgi?id=656433
Different bits of code were using slightly different checks to test
whether a window was an attached dialog. Add a new
meta_window_is_attached_dialog(), and use that everywhere.
Also, freeze the is-attached status when the window is first shown,
rather than recomputing it each time the caller asks, since this could
cause problems if a window changes its type after it has already been
attached, etc. However, if an attached window's parent is destroyed,
or an attached window changes its transient-for, then fix things up by
destroying the old MetaWindow and creating a new one (causing
compositor unmap and map events to be fired off, allowing the display
of the window to be fixed up).
Remove some code in display.c that tried to fix existing windows if
the gconf setting changed, but which didn't actually do anything (at
least under gnome-shell). However, if 654643 was fixed then the new
behavior with this patch would be that changing the gconf setting
would affect new dialogs, but not existing ones.
https://bugzilla.gnome.org/show_bug.cgi?id=646761
The code here was wrong in every way: it only updated the shape if all the
borders changed. It never saved new last_borders even if it *had* changed,
and the bounding rectangle's x and y positions were still important otherwise.
This had user-visible impact when doing simple things like changing the
border_width. It would short-circuit here and due to the above incorrectness,
weirdness could happen where windows would be cut off and so on.
https://bugzilla.gnome.org/show_bug.cgi?id=656334
gtk:custom() requires a fallback color in case the GTK+ theme in use
does not define the desired color. As in general the fallback color
will approximate the intended color, there is the risk of typos going
unnoticed. To make catching these kind of errors easier, allow to ignore
the fallback color specified (and fall back to a nice shade of pink
instead) by setting an environment variable.
https://bugzilla.gnome.org/show_bug.cgi?id=656112
get_outer_rect now returns the visible region, and a new get_input_rect
method returns the boundaries of the full frame, including the possible
invisible regions. When undecorated, both do the samething.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Just a quick little commit to help clean things up for when we add invisible
borders. Additionally, do a little housekeeping in preview-widget as well.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
There were actually *two* MetaFrameGeometry structs: one in theme-private.h,
one in frame.h. The latter public struct was populated by a mix of (void*)
casting and int pointers, usually pulling directly from the data in the private
struct.
Remove the public struct, replace it with MetaFrameBorders and scrap all
the pointer hacks to populate it, instead relying on both structs being used
in common code.
This commit should be relatively straightforward, and it should not do any
tricky logic at all, just a sophisticated find and replace.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
Since we're not setting the frame's output shape any more, it doesn't
make sense to calculate the output shape based on the frame window.
Instead, track the client window directly and calculate the output shape
based on that.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
In preparation for switching to handling the output shape purely by what we
paint, stop applying a shape to the frame of the window. Even when we restore
handling the output shape, this will change the behavior with respect to input;
transparent areas between the frame and the contents will stop clicks rather
than passing them through, but that is arguably at least as expected
considering how that we decorate shaped windows with a frame all around.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
We were leaving some members of the button_layout struct uninitialized if the
pref string didn't have at least one colon or if it was an empty string ("").
https://bugzilla.gnome.org/show_bug.cgi?id=654539
MetaShapedTexture can be a ClutterX11TexturePixmap sub-class, given that
ClutterGLXTexturePixmap is just a shim compatibility layer since Clutter
1.4, and it's been deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=655064
meta-texture-rectangle and meta-shaped-texture both create textures
with GL_TEXTURE_RECTANGLE_ARB as the target using direct GL
calls. This patch moves that code into a shared utility function in a
separate file instead. The function resolves the required GL symbols
dynamically instead of linking to them directly so that if Clutter
eventually stops linking to -lGL mutter will continue to build. The
function also splits the texture creation into a separate texture
creation and data upload stage so that it can use
cogl_texture_set_region to upload the data. That way it can avoid
clobbering the glPixelStore state and it can let Cogl do any necessary
format conversion. The code preserves the old value of the rectangle
texture binding instead of clobbering it because Cogl expects to be
able to cache this value to avoid redundant glBindTexture
calls. Finally, the function uses cogl_object_set_data to
automatically destroy the GL texture when the Cogl texture is
destroyed. This avoids having to have special code to destroy the cogl
texture.
https://bugzilla.gnome.org/show_bug.cgi?id=654569
texture_tower_revalidate_fbo() called cogl_flush() to work around
clutter bug #2110, which has been long fixed.
As we depend on clutter 1.7.x anyway we can just remove that workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=654729
Clutter now has some API to get the bounds of the current redraw clip
so Mutter no longer needs to make direct GL calls to get the scissor
rect. This should make it more robust against Cogl or Clutter changing
how it does the clipping.
https://bugzilla.gnome.org/show_bug.cgi?id=654551
Calling meta_later_add() or meta_later_remove() from within a
META_LATER_BEFORE_REDRAW callback ended up being a no-op, because of
how run_repaint_laters() was fiddling with the laters list. (This
resulted in a crash in window.c:idle_calc_repaint(), which assumed it
would only be called when a certain queue was non-empty, but was
getting called anyway because of a failed meta_later_remove() call.)
Fix this by having run_repaint_laters() work on a copy of the laters
list instead, and add refcounting to MetaLater so that removing a
later that run_repaint_laters() hasn't gotten to yet won't cause
problems.
https://bugzilla.gnome.org/show_bug.cgi?id=642957
When we get a press of the overlay key, and then another key is pressed,
first try to handle the combination as a global keybinding. If that fails,
call XAllowEvents(..., ReplayKeyboard, ...) to let it be handled by
our per-window keybindings or by the application.
This requires restructuring things to call XAllowEvents a bit later
so we can pass the right mode.
https://bugzilla.gnome.org/show_bug.cgi?id=624869
meta_frames_destroy() was not safe to be called multiple times, which
was causing a crash on exit due to something else changing somewhere
that makes it get called multiple times.
https://bugzilla.gnome.org/show_bug.cgi?id=654489
- menus have a very subtle shadow, define the outline better. Required for gtk theming.
- focused windows are better identified now as unfocused windows have a subtle shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=649374
A x/y typo that was causing shadow bounds to be incorrectly
computed and trails to be left in some circumstances. Behavior
noted by Jakub Steiner.
https://bugzilla.gnome.org/show_bug.cgi?id=649374
The code assumed that the focus window was always the one at the
top of the window stack, which is not true if an unfocused window
has the above hint set.
Rather than fixing this assumption, rename the function to
lower_beneath_grab_window() and use the display's grab window - the
function is only used for displaying the tile previews, which means
that we want the grab window anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=650661
Add an additional color type to pick up colors defined with
@define-color in the GTK+ theme's CSS:
gtk:custom(name,fallback)
(where "name" refers to the name defined in GTK+'s CSS, and fallback
refers to an alternative color spec which is used when the color
referenced by "name" is not found)
The main intent of the change is to allow designers to improve
Adwaita's dark theme variant without having to compromise on colors
which work in the light variant as well.
https://bugzilla.gnome.org/show_bug.cgi?id=648709
This patch fixes an issue encountered when building mutter
out-of-tree:
* When generating mutter-enum-types.[ch], the glib-mkenums command is
executed from $(srcdir), so it is wrong to prepend $(srcdir) to the
template file.
https://bugzilla.gnome.org/show_bug.cgi?id=624910
We now use GtkStyleContext exclusively, so it's a bit weird to store
widget state as GtkStateType and translate it always to GtkStateFlags.
Just use GtkStateFlags instead of GtkStateType.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
GtkStyleContext no longer has dark/light colors GtkStyle used to
have. We already have compatibility code for them in theme.c, so
add two helper functions to make it available outside theme.c.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
GdkColor is about to be deprecated, so move to GdkRGBA instead.
It might be worth considering using cairo patterns for the gradients
rather than using custom code to render gradients to a pixbuf which
is then drawn with cairo, but for now this is just a straight port
of the existing code.
https://bugzilla.gnome.org/show_bug.cgi?id=650586
When detaching/attaching a dialog, we were only updating
appears-focused on the parent if the child itself was focused, but in
fact, we need to do it if the child has an attached child which is
focused too.
To simplify the case of detaching a focused subtree from its parent,
we change meta_window_propagate_focus_appearance() to use
@window->display->focus_window as the window to add/remove as the
attached_focus_window, and @window only as the starting point to
propagate from. That way we can propagate focus-removal up to
@window's (soon-to-be-ex-)ancestors without having to remove it from
its descendants as well.
https://bugzilla.gnome.org/show_bug.cgi?id=647712
Don't set a window's xtransient_for if it would create a loop. Since
this is the only place we ever set xtransient_for, we can therefore
assume everywhere else that it does not loop.
https://bugzilla.gnome.org/show_bug.cgi?id=647712
Back the API version down to 3.0; since we don't make any stability
guarantees, there's no reason to have a merry-go-round of different
directories and filenames that people have to keep up with.
According to the XShape specification, the shaped region should always be
a subset of the bounding region. Certain programs such as wine depended
on this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=627880
* When unmanaging a screen, stop redirecting subwindows explicitly,
so that we do that before destroying the window manager selection
window.
* Improve comment in the retry code
* When exiting because the previous compositor couldn't be replaced,
don't g_error() and drop a core file.
https://bugzilla.gnome.org/show_bug.cgi?id=653121
When there was no root background pixmap, we were using a 1x1 repeating
texture as a simple way of drawing a solid color without adding a
second code path. However, when that 1x1 texture was combined into
a larger "atlas texture", hardware repeat couldn't be used, so a
small inefficiency from this approach became an enormous inefficiency
as clutter drew every pixel of the background as a separate rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=652507
When left-clicking the frame border with the titlebar being
off-screen, rather than starting the expected grab operation the
window menu was popped up.
This behavior is pretty confusing, especially since the menu button
was removed from the default layout, making right-clicking the only
way to get to the window menu.
https://bugzilla.gnome.org/show_bug.cgi?id=652369
meta_run() calls meta_finalize() after the main loop exits, which ends
up calling meta_display_close(), which calls
meta_quit(META_EXIT_SUCCESS), meaning that any exit status passed to
the original meta_quit() call is lost.
Fix this by ignoring meta_quit() calls after the main loop is no
longer running.
https://bugzilla.gnome.org/show_bug.cgi?id=652010
Like the setting of new frames' background is delayed until the
frame is associated with its window, delay attaching the initial
style, so that the correct style variant is picked.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
When the _GTK_THEME_VARIANT property changes, rather than just
updating the window's theme_variant property, update its frame
style as well, so that the window decoration reflects the requested
variant. As the initial properties of a window may be read before
its frame is created, there will be cases where the change is not
picked up initially.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
In order to pick up colors from a GtkStyleContext, a temporary
GtkStyle object was created from the context and destroyed after
copying the requested GdkColor. This is slightly inefficient, so
get the appropriate GdkRGBA from the context and translate it to
a GdkColor, based on the compatibility code in gtkstyle.c.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
Rather than sharing a single style context between all frames, use
a default style and one style per encountered variant (as determined
by the _GTK_THEME_VARIANT property), so that colors from the GTK+ style
are picked from the correct theme variant.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
Since version 3.0, GTK+ has support for style variants. At the moment,
themes may provide a dark variant, which can be requested by
applications via GtkSettings. The requested variant is exported to
X11 via the _GTK_THEME_VARIANT property - support this property, in
order to pick up the correct style variant in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
Rather than using a single widget's style for GTK+ colors in themes,
use the style context parameter of the drawing functions for those
colors. Right now, a single style context is shared between frames,
but this will change to support different style variants.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
To determine the correct background style, the UI needs to access
some frame properties via meta_core_get(); this call will bail out
early if window->frame is unset, so delay the call until the
association is made.
https://bugzilla.gnome.org/show_bug.cgi?id=645355
gdk_cairo_set_source_rgba() is a convenience function which was
added to GTK+-3.0 after the port to GtkStyleContext, so we ended
up using cairo_set_source_rgba() instead. Save a couple of lines ...
For the purposes of window placement or arranging window manager or
plugin controls, screens that are just mirrors of other screens should
be ignored, so filter them out of the monitors list.
https://bugzilla.gnome.org/show_bug.cgi?id=649299
If a window is not maximizable, then that probably means it looks dumb
at very large sizes. Even if its hints would allow you to manually
resize it to a large size, don't allow automatically tiling it to half
the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=647901
If a window had no title property set, then the
application-not-responding dialog would cause Mutter to crash
because window->title was NULL; handle that case and use the
string "Application is not responding."
https://bugzilla.gnome.org/show_bug.cgi?id=649114
Command line arguments are supposed to be in the locale encoding,
not UTF-8, and Zenity decodes command line string command line
arguments with this assumption using GOption.
There was a half-hearted attempt to deal with this in delete.c,
but it wasn't correct since it immediately mixed the window title,
converted to the locale encoding with a UTF-8 message.
https://bugzilla.gnome.org/show_bug.cgi?id=649114
As a library, libmutter should not be setting the default translation
domain to point to itself.
Also, move the bindtextdomain() call earlier
(meta_get_option_context), so that translations of command-line
options will be available.
We could call textdomain() in mutter.c, but there's no need to, since
mutter uses dgettext() everywhere anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649202
Previously, the restart command hardcoded "mutter" as the binary name.
This commit changes it to use g_get_prgname() which has a better chance
of being correct (and it does fix session saving for gnome-shell).
Now that mutter is a library, it might be more correct (but also
much higher overhead) to add api for setting these things from
the outside.
https://bugzilla.gnome.org/show_bug.cgi?id=648828
An ARGB window with a frame is likely something like a transparent
terminal. It looks awful (and breaks transparency) to draw a big
opaque black shadow under the window, so clip out the region under
the terminal from the shadow we draw.
Add meta_window_get_frame_bounds() to get a cairo region for the
outer bounds of the frame of a window, and modify the frame handling
code to notice changes to the frame shape and discard a cached
region. meta_frames_apply_shapes() is refactored so we can extract
meta_frames_get_frame_bounds() from it.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
It's useful to get frame shapes and manipulate them within Mutter, for
example so that the compositor can use them to clip drawing.
For this, we'll need the regions as cairo regions not X regions, so
convert frame shaping code to work in terms of cairo_region_t.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
Using MetaWindowActor.opacity for _NET_WM_WINDOW_OPACITY makes it
difficult to implement effects like fading a window in on map.
Instead, set the opacity on the MetaShadedTexture child and use
it when drawing the shadow.
Since the check MetaWindowGroup does on meta_actor_get_paint_opacity()
no longer covers this, we need to handle the opacity in
meta_window_actor_get_obscured_region() explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=648613
If a window can not be tiled, e.g. due to its minimum size hints,
dragging away from the top after activating the maximize tile preview
does not cancel the maximization request, the only way to do so is by
hitting Escape.
To fix, reset the tiling state in the maximize-tile code path as
well if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=646149
Apparently the "fox" toolkit doesn't set WM_CLIENT_MACHINE; while we
could do gymnastics to attempt to figure this out (talk to the X
server?), better to just default to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=647662
Since appears-focus only propagates up from modal dialogs, if an
application removed the modal hint from a dialog before destroying it,
then its parent would be left with a stray reference to it in
attached_focus_window, causing it to be permanently appears-focused.
The obvious fix, calling meta_window_propagate_focus_appearance() when
the modal hint is removed, tends to cause noticeable flashing, because
the window will get drawn unfocused and then focused again.
So instead we just change meta_window_propagate_focus_appearance() to
check the window type only when focusing in, not when focusing out.
This would also cause flashing, but in this case we can avoid it by
not notifying the change in appears-focus on the parent window if it
is the expected_focus_window (which it will be by this point). (This
does mean though that if something weird happens and the window
doesn't end up becoming the focus window, it won't get redrawn
unfocused until something else forces it to.)
https://bugzilla.gnome.org/show_bug.cgi?id=647613
We need to redraw a window's shadow any time the value of
meta_window_appears_focused() changes. So make that into a property so
we can get notifications on it.
https://bugzilla.gnome.org/show_bug.cgi?id=636904
This is necessary for gnome-shell to know whether it should try to
replace the org.gnome.Shell DBus name.
Note: We can't just #include <meta/util.h> because it #defines '_'
at least which obviously conflicts with core gettext. We should
un-export util.h or fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=645590
As the position of attached modal dialogs is determined entirely
by the position of the parent window, the dialog may end up
partially off-screen (especially if the dialog is wider than the
parent). In this case, diverge from the calculated position and
try to fit the dialog on-screen.
https://bugzilla.gnome.org/show_bug.cgi?id=631308
This is useful for DnD to another monitor in gnome-shell.
In addition to a normal move it corrects the saved rect for
maximized and fullscreened windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645032
Currently attached modal dialogs are not resizable, but we don't
communicate this to GTK+, so the dialog may end up with resize
grips anyway. As a fix, allow resizing, but account for the dialog
being centered to its parent.
https://bugzilla.gnome.org/show_bug.cgi?id=643597
Getting the contents of a depth-1 pixmap through cairo gives us
an alpha pixmap. We need to convert to a monochrome pixmap
as is expected by the ICCCM definition of WM_HINTS.
https://bugzilla.gnome.org/show_bug.cgi?id=641975
apply_mask made some wrong assumptions that became untrue
after rendering_cleanup landed, such as the number of channels
in the pixmap, causing corruption.
https://bugzilla.gnome.org/show_bug.cgi?id=641975
Currently, attached modal dialog can be grabbed (either by the
title bar, or using Alt+Button1), though they won't move when
dragged. To address this, grab the parent in that case, which
allows to move both the parent and the attached dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=638674
Commit 96c43866 changed the tiling behavior to prefer edge tiling
over maximization in corner cases (well, quite literally). As a
side effect, it only allows untiling of edge-tiled windows by
dragging the window towards the correct edge.
This patch restores the old behavior for untiling, while keeping
the new behavior for untiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645455
For tiling, we check whether the pointer is near the edges of
the monitor where the pointer is located, so checking that the
pointer is within the bounds of the monitor is unnecessary and
confusing.
Mark that the the third argument to meta_rectangle_union and
meta_rectangle_intersect is an (out) argument that should be created
by the language binding.
https://bugzilla.gnome.org/show_bug.cgi?id=645247
If dragging the title bar to the edge of the screen to side-tile,
it's easy to end up above the workarea and end up maximized instead.
Make the entire side of the screen act as edge-tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=644961
In a performance or regression testing environment, we may want to
only manage windows from a particular test program, and ignore all
other windows. The MUTTER_WM_CLASS_FILTER environment variable is a
list of WM_CLASS values that should be managed; other windows will
be unmapped and ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=644252
gtk3 no longer has the --screen command-line argument, which mutter
was passing to zenity. Use --display (with an explicitly-specified
screen number) instead.
https://bugzilla.gnome.org/show_bug.cgi?id=643683
This made sense back in the day of stateless window managers,
but gnome-shell isn't. gnome-session will handle gnome-shell
crashing, since it's a required component.
https://bugzilla.gnome.org/show_bug.cgi?id=644529
This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.
on_all_workspaces means this window is visible on all workspaces.
on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.
Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Until the actor is destroyed, we need to have access to the
MetaWindow to access some fields used for painting. Keep a strong
reference to the window rather than just hoping the window will
not be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=642787
We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
The latter move method will place the window by the origin of the
enclosing window decoration/frame, while the former will place by the
origin of the inner window, itself.
(Also moved meta_window_showing_on_its_workspace comment into
gtk-doc)
https://bugzilla.gnome.org/show_bug.cgi?id=642355
When reload_net_wm_state() is called at startup to read the initial
value of _NET_WM_STATE, it was calling recalc_window_type(), but not
recalc_features(), which meant that, eg, meta->skip_taskbar would
never get initialized from meta->wm_state_skip_taskbar, which meant
that next time mutter went to update the window's _NET_WM_STATE, it
would overwrite the app-specified initial values. Fix that.
(In metacity, this bug is masked by the fact that recalc_features()
gets called when reading the intial value of WM_NORMAL_HINTS, which
comes after _NET_WM_STATE in metacity's prop_hooks_table. In mutter,
the table got reordered at some point, exposing the bug.)
https://bugzilla.gnome.org/show_bug.cgi?id=624360
