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
This commit is in preparation for the work happening in GTK3, which will
use Cairo for drawing exclusively. So it is necessary to move all
drawing code to Cairo. In this commit the "gtk2" code is used for both
gtk2 and gtk3; compatibility with newer versions of gtk3 where different
code is needed will be added subsequently.
For compatibility with older GTK versions, the file gdk2-drawing-utils.h
provides a compatibility layer.
The commit changes the API of libmutter-private.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
For functions (but not callback types), '(closure)' is used on the
callback parameter, and takes the name of the parameter which is
the closure/user data.
A maximized window can't be resized from the screen edges (preserves
Fitts law goodness for the application), but it's still possible
to start a resize drag with alt-middle-button. Currently we just
don't let the user resize the window, while showing drag feedback;
it's more useful to let the user "break" out from the resize.
This provides a fast way to get a window partially aligned with
the screen edges - maximize, then alt-drag it out from one edge.
Behavior choices in this patch:
- You can drag out a window out of maximization in both directions -
smaller and larger. This can be potentilaly useful in multihead.
- Dragging a window in only one direction unmaximizes the window
fully, rather than leaving it in a horizontally/vertically
maximized state. This is done because the horizontally/vertically
maximzed states don't have clear visual representation and can
be confusing to the user.
- If you drag back to the maximized state after breaking out,
maximization is restored, but you can't maximize a window by
dragging to the full size if it didn't start out that way.
A new internal function meta_window_unmaximize_with_gravity() is
added for implementing this; it's a hybrid of
meta_window_unmaximize() and meta_window_resize_with_gravity().
Port of the metacity patch from Owen Taylor in bug 622517.
https://bugzilla.gnome.org/show_bug.cgi?id=629931
The widget needs to be visible and mapped for GTK3 to deliver expose
events to the widget. This is achieved by making the map function a
no-op and calling gtk_widget_show() instead of just calling
gtk_widget_realize().
Apart from making GTK think the widget is drawable, the effect is the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=630203
