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
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
Similar to the recently added 'size-changed' signal, we may want to do
something in response to a window being repositioned without waiting for
notify::allocation. (Especially since what we can do in notify::allocation
is severely limited by Clutter forbidding queueing an allocation at that
point.)
https://bugzilla.gnome.org/show_bug.cgi?id=641310
If we are previewing hidden windows, we might be previewing them in a context
like a thumbnail view of a workspace where we care about positioning. So, instead
of waiting until the window is first actually shown to place it, if
live_hidden_previews is set, place the window window when we first compute its
visibility, even if we don't end up showing it.
https://bugzilla.gnome.org/show_bug.cgi?id=641309
A plugin that does workspace management on its on may want to set the
workspace layout without having to deal with putting a property
on the root window to be read back and parsed.
Add meta_screen_override_window_layout() that allows the same types
of layouts as _NET_DESKTOP_LAYOUT but without setting a property.
https://bugzilla.gnome.org/show_bug.cgi?id=640552
A logic bug was resulting in the bottom hidden window (hidden means means
minimized or on a different workspace) continually being stacked above
the other hidden windows.
https://bugzilla.gnome.org/show_bug.cgi?id=640679
When we delete a workspace before the active workspace, we need
to upate the _NET_CURRENT_DESKTOP since the active workspace index
changes. To do this workspace.c:set_active_space_hint() is moved
to screen.c:meta_screen_set_active_workspace_hint() so that it
can be shared.
https://bugzilla.gnome.org/show_bug.cgi?id=640581
Emit a signal when the window size changes. While it is already
possible to connect to notify::allocation (or width/height), the
new signal is emitted outside a clutter allocation cycle, which
makes it more convenient when adjusting an actor's size/position
in response.
On gcc-4.4 (void)<expr> doesn't suppress warnings from
__attribute__((warn_unused_result)), so use
G_GNUC_UNUSED (which expands to __attribute__((unused))) instead
of removing a dummy variable.
https://bugzilla.gnome.org/show_bug.cgi?id=640508
As the tile preview is shown or hidden when a window is dragged
around, it may stick around if the drag operation is cancelled.
Make sure that the preview is hidden in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
Drag operations may be cancelled, in which case the dragged window
should be restored to the position/state it had when the drag was
initialized. In order to do this for tiled states, the original
state has to be saved during the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
The previous tiling state of a grabbed window should be restored
if the drag operation is cancelled (by hitting the Escape key).
This might involve to meta_window_tile(), so export the function
in window-private.h.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
GtkStyle has been deprecated in favor of GtkStyleContext. A full
port would involve replacing GdkColor with GdkRGBA - leave this
out for the time being.
Bump the required version of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=637761
We want switching between the windows of an application to be an easily
accessible operation. The convenient and memorable keybinding is the
key above the tab key - but the keysym for that key isn't consistent
across different keyboard layouts.
Add code that figures out the key from the XKB geometry and a magic
keysym name "Above_Tab" that refers to this key and switch
the default binding for cycle_group to <Alt>Above_Tab. (This will
have no effect for the normal case of getting the key binding from
GConf until this patch is applied to Metacity as well.)
https://bugzilla.gnome.org/show_bug.cgi?id=635569
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=637330
With the existing background functions, single buttons can not be
styled separately - on the left side, the style of the left button
is picked, and the right button's style on the right side.
As theme authors may want to add rounded corners to button groups
as a whole, it makes sense to treat the case of a single button in
a group differently.
https://bugzilla.gnome.org/show_bug.cgi?id=635683
When validating button functions and frame styles, the required
format version of the features used in the theme was compared to
the major version number of the supported format, limiting additions
to major theme format bumps.
Use peek_required_version() instead, so the minor version number
of the supported theme format is taken into account.
https://bugzilla.gnome.org/show_bug.cgi?id=635683
While the configured layout is taken into account for positioning
the buttons, the mapping from button function states to button
position states just assumed the default button layout in LTR
locales.
Do a proper mapping depending on the actual layout instead.
https://bugzilla.gnome.org/show_bug.cgi?id=635686
This patch removes the ability to disable compositing in mutter. As
clutter compositing was the reason for the fork from metacity, turning
compositing off does not make sense.
https://bugzilla.gnome.org/show_bug.cgi?id=626875
To deal with reentrancy from compositor plugins doing things like
moving windows between workspaces in an effect callback, update
the visible_to_compositor flag before calling into the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
When a compositor is present, we keep the visibility state of the
compositor windows in sync with window->visible_to_compositor. We need
to do the same when enabling the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
* GL_TEXTURE_RECTANGLE_ARB not avaliable
* clutter_glx_texture_pixmap_using_extension / CLUTTER_GLX_TEXTURE_PIXMAP not avaliable
Signed-off-by: Andreas Mueller <schnitzeltony@gmx.de>
Commit 2c8c1c6df49 in gtk+ removed gdk_display_get_core_pointer().
The equivalent functionality can be achieved by using the
GdkDeviceManager to retrieve the client pointer device.
Maximized tiled windows end up with an inconsistent tile mode when
unmaximized by other means than dragging the window free (e.g.
using the unmaximize button or double clicking the title bar), so
reset the tile mode when unmaximizing.
This is not a problem for side-by-side tiling, as there are no
alternatives to dragging the window free.
When a tiled window is maximized (e.g. by clicking the title bar
button), unmaximizing the window restores the tiled state. While
this is reasonable for side-by-side tiling, it is confusing for
"maximize" tiled windows, as unmaximization has no visible effect.
Change unmaximize to only restore the tiled state of side-by-side
tiled windows.
The original patch triggered "maximize" when the window was dragged
to the top, so that the pointer was below or on the monitor edge and
above the work area's top.
If there's no chrome at the top of the monitor, so that monitor edge
and work area top fall together, the pointer cannot be moved above
the work area's top, so tiling was not triggered.
GTK is about to clean up its code and remove duplicate macros and
GdkDrawable usage. To prepare for that landing, we use the future-safe
versions of the same calls.
https://bugzilla.gnome.org/show_bug.cgi?id=636302
The old behavior of being able to shake loose a maximized window
overlaps with and is for the most part superceded by top edge tiling.
This commit changes the code to only enable shake loose behavior
when edge tiling is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
In addition to the existing side-by-side tiling modes, this commit
adds a new "maximize" tiling mode. It allows the user to maximize
their windows (in other words, tile with the edge panels) by dragging
their window to the top edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
The meta_window_handle_mouse_grab_op_event function ensures
the tile_mode variable is in a consistent state after a drag
op is finished.
The way this is current done is:
if (!window->maximized_vertically &&
window->tile_mode != META_TILE_NONE)
window->tile_mode = META_TILE_NONE;
While valid, it doesn't "read" as well as using the
META_WINDOW_TILED_SIDE_BY_SIDE macro, since the macro is specifically
about side-by-side tiling.
This commit just changes things to use the macro and to not bother
checking the tile mode (since if we just reset it anyway, then it doesn't
matter if the value is right or wrong to begin with).
https://bugzilla.gnome.org/show_bug.cgi?id=630548
Currently, the new tiling feature, supports side-by-side, horizontal
tiling when dragging windows to one of the vertical edges of a monitor.
Other types of tiling (on other monitor edges) are potentially useful,
though.
This commit renames the preference from side_by_side_tiling to
edge_tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
A direction parameter is passed to meta_compositor_switch_workspace(),
to indicate the direction of the switch depending on the workspace
layout.
In contrast to the switcher popup, this parameter does not take the
text direction of the locale into account. Change this, so that the
workspace switching animations move in the correct direction.
https://bugzilla.gnome.org/show_bug.cgi?id=636083
overlay_key_combo needs the same treatment as other keycodes on a
change - we should always recompute it if we have a keysym not
a keycode, and not only if the keycode hasn't already been
computed.
Simplify the keymap loading logic by unifying the different
branches; in the reorganization this patch fixes a bug where when
we got a MappingKeyboard event we wouldn't update virtual modifiers
correctly.
Based on a patch by Thomas Thurman <tthurman@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=565540
* Select for XKB keyboard notification events explicitly; since GTK+
has selected for XKB events, delivery of old-school MappingNotify
events is disabled.
* Fix a bug where once a keycode was loaded for a key binding,
it would never be reassigned; we want to laod new keycodes for
all bindings that have a key symbol rather than a fixed
keycode.
[ With fixes from Owen W. Taylor <otaylor@fishsoup.net> ]
https://bugzilla.gnome.org/show_bug.cgi?id=565540
Protect against shape_region or bounding_region being NULL in check_needs_shadow.
This can happen for short lived windows and result into a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=635421
Since we aren't depending on Clutter 1.5 or using the new
CoglPipeline name elsewhere, we need to stick to the old
COGL_MATERIAL_WRAP_MODE_* names, which are provided with
compatibility defines in Clutter 1.4.
Pointed out by Rico Tzschichholz
If we have repeats on for a full-sized image, then if the background
is displayed scaled (for example, in a desktop preview mode) then we
can get artifacts along the edge of the background where the repeat
of the opposite edge is blended in by bilinear scaling. So turn off
repeats when the screen and background image sizes match.
https://bugzilla.gnome.org/show_bug.cgi?id=634833
Add code to track and draw the root window background. The advantage of doing
it here as compared to in a plugin is that we can use the visiblity smarts
of MetaWindowGroup to optimize out drawing the background when obscured.
If handling other than tracking the _XROOTPMAP_ID property is desired in the
future, more functionality like setting the background from a file or doing
cross-fades can be added.
The new background actor is exposed to plugins via meta_plugin_get_background_actor()
similar to other exposed actors to allow cloning the background for use in
other displays. The actual class is not installed for public consumption at
the moment since it has no useful methods.
https://bugzilla.gnome.org/show_bug.cgi?id=634833
Create new cogl-utils.[ch] and move a helper function from
MetaShadowFactory there as meta_create_texture_material(); this
allows us to create single-layer materials from different parts of
Mutter and have them share the same template material.
Also expose a function for creating a 1x1 texture of a given
color meta_create_color_texture_4ub().
https://bugzilla.gnome.org/show_bug.cgi?id=634833
When in a partial stage paint, we can combine that with the visibility
information in MetaWindowGroup to further eliminate unneeded drawing.
Since there is no current Clutter API to access the current clip,
drop to using GL directly.
https://bugzilla.gnome.org/show_bug.cgi?id=634779
This is just a microptimization, as we pretty much always use
TFP (and do the check every time we set a pixmap),
we can let gcc generate better code here.
https://bugzilla.gnome.org/show_bug.cgi?id=633002
For various reasons (mostly the stack tracker correctly predicting the
stacking order before getting events, but also because of the processing
that the compositor does to get the actor stacking order) the compositor
can be told to sync the stack when it has nothing to do. Detect this
at the last moment before actually telling Clutter to restack to avoid
triggering unnecessary redraws.
https://bugzilla.gnome.org/show_bug.cgi?id=634771
Since we can't distinguish a ConfigureEvent that indicates a raise
from a ConfigureEvent that indicates a move, we get lots of
STACK_OP_RAISE_ABOVE events for windows that are already in the
right place in the stacking order. Avoid queueing a restack in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=634771
Fullscreen and maximized windows never have visible shadows - the only
case where we would ever see them is if they bleed onto an adjacent
monitor and that looks bad.
It's small performance win to avoid computing them, and this also avoids
painting the top shadow for all maximized windows in GNOME Shell - since
the top panel isn't a X window, it doesn't factor into the computation
of what parts of windows are visible and maximized windows are computed
as having a top shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
These functions duplicate existing properties; they are added for
convenience and to avoid the GObject property code on some
performance critical painting paths.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of making optimizing obscured shadows an all-or-none operation,
pass the clip region to meta_shadow_paint() and only paint the 9-slices
that are at least partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of setting shadow parameters on individual windows, add the
idea of a "shadow class". Windows have default shadow classes based
on their frame and window type, which can be overriden by setting
the shadow-class property.
Each shadow class has separably configurable parameters for the
focused and unfocused state. New shadow classes can be defined with
arbitrary names.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Frame types will form the bases of shadow classes, which are strings,
so export the to-string function so that we can do the conversion
uniformly.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The basic MetaShadowFactory type is moved to a public header, while
the functions to fetch and paint shadows are kept private.
The public object will be used for configuration of shadows by
plugins.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
For attached modal dialogs, we want the shadow to fade out at the top
as if the window was glued to the parent at the top. Add a
shadow-top-fade property to MetaWindowActor and the corresponding
parameter to meta_shadow_factory_get_shadow().
The internal implementation of MetaShadow is adjusted to work
in terms of an "inner border" and "outer border" instead of doing
the calculations in terms of an aggregate border and the spread
of the shadow. The old way of doing things gets clumsy when the
top_fade distance is added in as well.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Add a new frame type META_FRAME_TYPE_ATTACHED which is used for
attached modal dialogs.
The theme format version is bumped to 3.2, and attached windows
can have borders defined in a metacity-theme-3.xml as:
<window version=">= 3.2" type="attached" style_set="[name]"/>
If no style is defined for "attached", drawing will fall back
to the "border" type.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The current shadow code just uses a single fixed texture (the Gaussian
blur of a rectangle with a fixed blur radius) for drawing all window
shadows. This patch adds the ability
* Implement efficient blurring of arbitrary regions by approximating
a Gaussian blur with multiple box blurs.
* Detect when multiple windows can use the same shadow texture by
converting their shape into a size-invariant MetaWindowShape.
* Add properties shadow-radius, shadow-x-offset, shadow-y-offset,
shadow-opacity to allow the shadow for a window to be configured.
* Add meta_window_actor_paint() and draw the shadow directly
from there rather than using a child actor.
* Remove TidyTextureFrame, which is no longer used
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The size_request vfunc is going to be dropped in GTK3; replace
the usage in MetaAccelLabel and MetaPreview with
get_preferred_width/get_preferred_height vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=633352
In GTK+ 3, it's mandatory to have a GdkDevice in a synthesized event,
so fill in the pointer device for the events we synthesize and forward
to GTK+. Since gdk_event_set_device() only works for allocated events,
we need to switch to gdk_event_new() rather than using stack allocated
events.
https://bugzilla.gnome.org/show_bug.cgi?id=633401
Now that we create MetaWindow objects for override-redirect windows, we need
to check all key press events to see if they are on GTK+ widgets, not just
events that don't match a MetaWindow. This fixes a problem with alt-Tab stealing
grabs away from the window menu.
https://bugzilla.gnome.org/show_bug.cgi?id=633398
With client side windows, mixing GDK event delivery with explicit calls
to XUngrabPointer() can result in GDK losing button release events
it expects to get. This means that GDK thinks there is an implicit
grab in effect when there is none and send events to the wrong window.
Avoid this by bypassing GDK's event handling for most mouse events.
We do a simplified conversion of the X event into a GdkEvent and send
it to directly to libgtk for delivery.
We make an exception when a GDK grab is already in effect - this is
needed for the correct operation of menus.
http://bugzilla.gnome.org/show_bug.cgi?id=599181
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=633133
meta_display_process_key_event() always looks up events based on the
"default" keysym for the keycode, so we should do the same here. This
fixes, eg, the lookup of Shift-Alt-Tab (which would otherwise be
unrecognized because the keysym would be XK_ISO_Left_Tab rather than
XK_Tab).
https://bugzilla.gnome.org/show_bug.cgi?id=632155
In ui/fixedtip.c, use g_signal_connect instead of g_signal_connect_swapped
since we're not using the data pointer (and for clarity).
At the same time, ensure that both the GTK2 and the GTK3 code paths
have the correct signature for the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=633051
The code for defining a color as a constant had broken logic: it
would try to parse the color first as an double, then as an integer;
the second attempt would produce an error about overwriting the
already-set-GError. Then it would clear the error and store the constant
as a color.
Use the fact that colors have to start with a letter or #, divide the
space of constants into:
- Integers
- Doubles
- Colors
so we get good error messages. Based on a patch by
William Jon McCann <jmccann@redhat.com>.
Note that this breaks the ability to specify an integer constant as
identical to another integer constant (the same didn't work for doubles.)
I think this was an accidental side effect of the code and not something
that was intentional or people were relying on
https://bugzilla.gnome.org/show_bug.cgi?id=632116
Remove --allow-unprefixed option to the scanner, and fix resulting
problems:
* theme.h and boxes.h are split into a main -header and a private
header that includes stuff that is not generally useful and
hard to introspect. Merge theme-parser.h into theme.h.
* meta_display_get_atom() and meta_window_get_window_type_atom()
are marked as (skip)
* Fix annotation: (element-type Strut) => (element-type Meta.Strut)
https://bugzilla.gnome.org/show_bug.cgi?id=632494
Move all objects and functions namespaced with Mutter into the Meta namespace
to get a single consistent namespace. Changes that aren't simply changing mutter
to meta:
MutterWindow => MetaWindowActor
mutter_get_windows => meta_get_window_actors
mutter_plugin_get_windows => meta_plugin_get_window_actors
https://bugzilla.gnome.org/show_bug.cgi?id=628520
In many places, MetaRegion was being used entirely internally, rather
than for gtk2/gtk3 compatibility. In these cases, it's simpler to just
depend on cairo-1.10 (for both gtk2 and gtk3) and use cairo_region_t.
The few places where we did need GDK compatibility (GdkEvent.region and
gdk_window_shape_combine_mask) are replaced with a combination of
converting GdkRegion to cairo_region_t and conditional code.
https://bugzilla.gnome.org/show_bug.cgi?id=632474
Simplify the code by noting that when we have square end-caps, the
results of generic line path give the right pixel-aligned rectangle
for horizontal/vertical lines.
Add comments and remove some extra braces.
https://bugzilla.gnome.org/show_bug.cgi?id=630426
Currently mutter-window has its own type field, even though the same
information is already present in meta_window.
And while at it get rid of MetaCompWindowType, it is equally redundant.
https://bugzilla.gnome.org/show_bug.cgi?id=630363
Commit aa65f94c67 that started passing
cairo_t around broke offsets. Since passing cairo_t makes them
unnecessary, this patches removes them rather than fixing them.
This patch changes API.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
With the newest changes to GTK3, some things were changed. This patch
now uses the features introduced in gtk3-compat.h in previous patches.
This patch also introduces a macro named USE_GTK3 that is used to
differentiate between GTK3 and GTK2. Its main use is differenting
between expose and draw handlers for GtkWidget subclasses.
The draw vs expose handlers question is usually handled by using ifdefs
at the beginning and end to set up/tear down a cairo_t and then use it.
However, when the function is too different and too many ifdefs would be
necessary, two versions of the function are written. This is currently
the case for:
- MetaAccelLabel
- MetaFrames
https://bugzilla.gnome.org/show_bug.cgi?id=630203
Similar to the region compatibility shim, we will soon need a
compatibility shim around GdkPixmap/cairo_surface_t. For now, the patch
just introduces the compatibility layer.
This patch also does not include the function
meta_gdk_pixbuf_get_from_pixmap() as that function will need special
treatment in GTK3 anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
Rename meta_frames_paint_to_drawable() to meta_frames_paint() and make
it take a cairo_t as an argument instead of creating the cairo_t itself.
This patch refactors code for GTK3 changes where code needs to handle
cairo_t and not GdkDrawable arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
