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
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
Move all of the mutter code into a new libmutter-wm.so, split its
main() method into meta_get_option_context(), meta_init() and
meta_run(), add methods for using in-process plugins, and add
libmutter-wm.pc pointing to the new library.
The mutter binary is now just a tiny program that links against
libmutter-wm. The --version and --mutter-plugins options are handled
at the mutter level, not in libmutter-wm, and a few strange unused
command-line options (--no-force-fullscreen and --no-tab-popup) have
been removed.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
meta_restart() was broken, in that it restarted mutter with what was
left of argv after GOption and Clutter had possibly modified it.
Rather than try to fix this, just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
Revert the early_initialize changes (which get in the way in the
"libmutter-wm" paradigm), remove the GConf key for setting plugins,
and remove plugin "params", which weren't being used. Also remove all
the logic for unloading and reloading plugins, since the list never
changes after startup now.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
This changes the introspection configure flag from
--with/--without-introspection to --enable/--disable-introspection,
and changes it so that trying to enable introspection when g-i is not
installed results in an error, rather than being silently ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
It looks amazingly lame if we simply call exit() during logout. While
it's true that for applications that use XSMP, gnome-session will
close them before us, that doesn't do anything for non-XSMP apps,
which we really hope is the common case.
Instead, we just go away when the X server does.
https://bugzilla.gnome.org/show_bug.cgi?id=643437
For GNOME Shell, we need to grab our DBus names *before* we talk XSMP.
gnome-session takes our XSMP connection as "I'm ready", and starts
running all the other random crud that people dropped in as autostart
files. But for example, we need to have claimed
org.freedesktop.Notifications before a lot of said crud starts.
This requires a plugin API version bump.
Misc: Move handling of --version way earlier in main() where
it should be; no point having it wedged after plugin handling.
If we handle a key event then passing it to GTK+ as well can only
cause confusion. Normally GTK+ would do nothing with a key event for
some window it doesn't know about, but plugins might be doing more
things with the GTK+ event queue.
https://bugzilla.gnome.org/show_bug.cgi?id=642426
If a plugin was explicitly specified, falling back to the default
silently is bad; a manager component like gnome-session can
do a better job of handling this scenario.
An example we've hit in gnome-shell is where SpiderMonkey changes
without gjs being rebuilt, and loading the plugin fails due to
unresolved symbols.
But there are obviously others, like the file being missing or
corrupt.
https://bugzilla.gnome.org/show_bug.cgi?id=641384
