A placement rule is always about placing a window relative to its
parent. In order to eventually place it against predicted future parent
positions, make the placement rule processing output relative
coordinates, having the caller deal with turning them into absolute.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Add support for assigning a window a custom window placement rule used
for calculating the initial window position as well as defining how a
window is constrained.
The custom rule is a declarative rule which defines a set of parameters
which the placing algorithm and constrain algorithm uses for
calculating the position of a window. It is meant to be used to
implement positioning of menus and other popup windows created via
Wayland.
A custom placement rule replaces any other placement or constraint
rule.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Instead of passing around MetaFrameBorders, compute it when we need it.
This also allows us to know that we are using MetaFrameBorders only for windows
with frames (where it is meaningful) and not for frameless windows, which
can have custom borders which we need to interpret differently.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
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
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
Code:
All references in the code not related to themes, keybindings, or
GConf were changed from 'metacity' to 'mutter'. This includes, among other
things, strings, comments, the atoms used in the message protocol, and
the envvars used for debugging. The GConf schema file was reduced to
the 3 settings new to mutter.
The overall version was brought up to 2.27 to match current gnome.
Structure:
All files named '*metacity*' were renamed '*mutter*' with appropriate
changes in the automake system. Files removed are
doc/creating_themes, src/themes, doc/metacity-theme.dtd,
metacity.doap. These files will eventually end up in an external
gnome-wm-data module.
Installation location:
On the filesystem the mutter-plugindir was change from
$(libdir)/metacity/plugins/clutter to just $(libdir)/mutter/plugins.
The mutter-plugins.pc.in reflects these changes.
Note:
mutter.desktop.in and mutter-wm.desktop both continue to have
X-GNOME-WMSettingsModule=metacity set. This allows
gnome-control-center to continue using libmetacity.so for
configuration. This is fine since most the general keybindings and wm
settings are being read from /apps/metacity/* in gconf.
2008-05-19 Iain Holmes <iain@gnome.org>
* src/include/frame.h
* src/include/display.h
* src/include/xprops.h
* src/include/compositor.h
* src/include/types.h
* src/include/window.h
* src/include/errors.h
* src/include/screen.h: New basic public API for compositor.
* src/compositor/*: Separate the compositor out into its own
separate
directory and set it up for backends. Initial XRender backend.
* src/core/compositor.[ch]: Remove
* src/core/frame.h
* src/core/screen.h
* src/core/display.h
* src/core/window.h: Rename to -private.h so as not to clash
with the
new files in include
* src/core/delete.c
* src/core/workspace.h
* src/core/stack.[ch]
* src/core/keybindings.[ch]
* src/core/errors.c
* src/core/effects.[ch]
* src/core/core.c
* src/core/group.h
* src/core/edge-resistance.[ch]
* src/core/window-props.[ch]
* src/core/constraints.h
* src/core/bell.[ch]
* src/core/iconcache.h
* src/core/session.[ch]
* src/core/main.c
* src/core/place.h
* src/core/xprops.c
* src/ui/tabpopup.c: Use the new -private headers
* src/core/display.c
* src/core/frame.c
* src/core/window.c
* src/core/screen.c: Add the API functions required by the
compositor
* src/Makefile.am: Relocate the new files
svn path=/trunk/; revision=3715
2007-12-19 Havoc Pennington <hp@redhat.com>
* src/ui, src/core, src/include: sort source files into these
directories according to which part of the WM they are supposed to
be in. In an eventual plan, we should also create
src/compositor/render, src/compositor/fallback and move some of
the compositor stuff into that.
* autogen.sh: require a newer automake, so we don't have to use
a recursive build
* src/ui/tabpopup.c: put in a hack to make the build temporarily
work, want to commit the large rearrangement before fixing this
not to include workspace.h or frame.h
* src/core/iconcache.c (meta_read_icons): temporarily break this
to get the build to work, want to commit the large rearrangement
before fixing this file not to include theme.h
svn path=/trunk/; revision=3491
