Commit Graph

7314 Commits

Author SHA1 Message Date
Rico Tzschichholz
ec8ba4b5f9 build: Move data files to their dedicated subfolder 2014-06-05 10:50:15 +02:00
Carlos Garnacho
2250865eb6 wayland: Implement the server side bits of wl_touch_interface
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.

The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.

The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.

https://bugzilla.gnome.org/show_bug.cgi?id=724442
2014-06-04 23:37:45 +02:00
Rico Tzschichholz
847a3bbee3 build: Fix some warnings and clean up a bit 2014-06-04 19:31:37 +02:00
Rico Tzschichholz
410a002ddd build: Do not distribute generated desktop-files 2014-06-04 16:13:11 +02:00
Rico Tzschichholz
8766db2593 common: Do not leak MetaResizePopup to the public api 2014-06-04 15:53:29 +02:00
Jasper St. Pierre
e362227514 window-x11: Don't ever send ConfigureNotifies for OR windows
There's a race here. If an OR window hides itself, moves, and then shows
itself, we will send a ConfigureNotify for the old size of the window
and might receive it after the client moves itself, causing us to show
the window at the wrong location.

Simply not sending the ConfigureNotify is the easiest thing to do.
2014-06-03 11:35:20 -04:00
Jasper St. Pierre
da311f266d window: Make sure to update client_rect for OR windows too
Before we unmanage, we send a ConfigureNotify to clients to let them
know if their frame is destroyed. We do this for OR windows too, even if
we really probably shouldn't.

This is based off of the client_rect. Since we listen to ConfigureNotify
on OR windows, we'll receive the event. If we don't ever update the
client_rect when moving or resizing OR windows, then we'll send
ourselves a ConfigureNotify for a 0x0 size and then think that the
client chose a new size for itself. Since our get_paint_volume is based
on that rectangle, but the TFP code inside Cogl uses XGetGeometry
itself, we get weird flickering artifacts.
2014-06-03 11:35:19 -04:00
Rico Tzschichholz
f5a4e996a8 display: Remove the screen from get_tab_list 2014-06-03 14:40:15 +02:00
Florian Müllner
a7f083897f frames: Only skip updating prelight when both control and state match
prelit_control is used for both prelight and pressed states, so the early
return in update_prelit_control() misses the case where prelit_control
already matches the control we are updating, but its state is PRESSED
rather than PRELIGHT. Fix the condition to not have pressed controls
linger around erroneously.

https://bugzilla.gnome.org/show_bug.cgi?id=731058
2014-06-02 23:49:48 +02:00
Florian Müllner
e2105dc721 frames: Fix pressed state of window menu buttons
Since window menus have been moved to the compositor, the pressed
state of the corresponding window buttons is messed up, as it is
reset immediately when getting a LeaveNotify event due to the
compositor taking a grab. Fix this by ignoring that particular
event.

https://bugzilla.gnome.org/show_bug.cgi?id=731058
2014-06-02 23:49:48 +02:00
Florian Müllner
b64548ee1f Pass button_rect when opening window menu from button
When opening the window menu without an associated control - e.g.
by right-clicking the titlebar or by keyboard - using coordinates
for the menu position is appropriate. However when the menu is
associated with a window button, the expected behavior in the
shell can be implemented much easier with the full button geometry:
the menu will point to the center of the button's bottom edge
rather than align to the left/right side of the titlebar as it
does now, and the clickable area where a release event does not
dismiss the menu will match the actual clickable area in mutter.

So add an additional show_window_menu_for_rect() function and
use it when opening the menu from a button.

https://bugzilla.gnome.org/show_bug.cgi?id=731058
2014-06-02 23:49:48 +02:00
Jasper St. Pierre
53425fa721 window: Make sure not to respond to input events on OR windows
This can happen since we select for events on the root window, and
clients themselves might not select for input, meaning the X server
will bubble up. Just do nothing and ignore the event in this case.

This should hopefully fix some of the

Window manager warning: Log level 8: meta_window_raise: assertion '!window->override_redirect' failed
Window manager warning: Log level 8: meta_window_focus: assertion '!window->override_redirect' failed

spam that people have been seeing.
2014-06-02 15:51:41 -04:00
Jonas Ådahl
048f035d30 wayland: Scale smooth scroll events to pointer motion coordinate space
Smooth scroll event vectors from clutter have the same dimensions as the
ones from from Xi2, i.e. where 1.0 is 1 discrete scroll step. To scale
these to the coordinate space used by wl_pointer.axis
vertical/horizontal scroll events, multiply the vector by 10.

https://bugzilla.gnome.org/show_bug.cgi?id=729601
2014-05-31 14:22:10 +02:00
Jasper St. Pierre
b32c837df9 window: Fix placement not actually placing windows
Since we often call meta_window_move_resize_now immediately after
mapping a window, we need to make sure that the placed coordinates
are saved in the unconstrained_rect. Ideally, placement positions
wouldn't be part of the constraints system, but instead are just
done inside meta_window_move_resize_internal as part of a special
path.

We're still working out the kinks of one large-scale refactor, so
it's best not to do another one while the first is going on. This
would be a great future cleanup, though: untangling constraints
and placement, alongside the force_placement state machine and
friends.
2014-05-29 14:09:57 -04:00
Jasper St. Pierre
dd03a76d51 place: Reindent 2014-05-29 13:58:08 -04:00
Jasper St. Pierre
806a666950 Make the native backend build-optional 2014-05-29 12:43:08 -04:00
Jasper St. Pierre
b240a5e819 keybindings: Only add VT keybindings if we're using the native backend 2014-05-29 12:43:07 -04:00
Jasper St. Pierre
fe823b3553 events: Improve check for native backend 2014-05-29 12:43:07 -04:00
Florian Müllner
d380d30ef4 Update (allow-none) annotations
The annotation has been deprecated in favor of (nullable) and/or
(optional).
2014-05-28 21:55:03 +02:00
Jasper St. Pierre
1fe5b3e7d5 window: Construct the frame before the initial move_resize
This ensures sure that the initial ConfigureRequest we make is
correct.
2014-05-28 11:47:14 -04:00
Jasper St. Pierre
a8df208a5c window-x11: Keep flags where they're used
Just a simple code cleanup
2014-05-28 11:43:11 -04:00
Jasper St. Pierre
f3f3c94831 frame: Don't reset window->rect 2014-05-28 10:50:23 -04:00
Jasper St. Pierre
6e06648f7a window: Refactor all move/resize operations to be in frame rect space
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.

For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.

This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.

Expect some regressions from this. Sorry for any temporary regression
that this might cause.
2014-05-27 15:44:34 -04:00
Jasper St. Pierre
afb41f715b core: Make META_CORE_GET_FRAME_RECT return the "frame rect"
We have two different coordinate spaces here. One is the rectangle
returned by meta_window_get_frame_rect, which is called the "frame
rect" or "the window geometry", which includes visible frame borders
but not invisible frame borders. The other is "frame->rect" which
corresponds to the frame's server geometry. That is, it includes
both visible and invisible frame borders.

These two were of course the same until we introduced invisible
frame borders, and an executive decision was made to make
meta_window_get_frame_rect return the rectangle bounding the
visible portions of the frame.

As time went on, the "frame rect" turned out to be more useful when
making decisions upon, since the user often doesn't think about the
invisible window geometry as part of the window.

We already calculate what amounts to the "frame rect" in the theme
code, so just change META_CORE_GET_FRAME_RECT to consume that
directly.
2014-05-27 15:44:33 -04:00
Jasper St. Pierre
19d26dde92 core: Convert GET_FRAME_WIDTH / GET_FRAME_HEIGHT to GET_FRAME_RECT
Since we're going to be calling meta_window_get_frame_rect in here
soon, I'd rather it be one method call, rather than two. We can't
put it at the toplevel, since that might cause infinite recursion
(e.g. meta_core_get calls meta_window_get_frame_rect calls
meta_ui_get_frame_borders calls meta_core_get, ...)
2014-05-27 15:44:33 -04:00
Jasper St. Pierre
4acb902423 window: Correct the anchoring of drag moving / resizing
Now that meta_window_move_resize and friends act in frame rect
coordinates, we need to convert the initial grab_anchor_window_pos
storage to be in frame rect coordinates as well.
2014-05-27 15:44:33 -04:00
Jasper St. Pierre
626516d12e window: Remove meta_window_move as well
Move to meta_window_move_frame everywhere...
2014-05-27 15:44:33 -04:00
Jasper St. Pierre
1c94df2553 window: Replace meta_window_resize_with_gravity with a frame-rect variant
More low-hanging fruit for our window geometry cleanups...
2014-05-27 15:44:33 -04:00
Florian Müllner
43762da9d3 Bump version to 3.13.2
Update NEWS.
2014-05-27 21:18:25 +02:00
Jasper St. Pierre
266166a2d6 window: Make meta_window_unmaximize_with_gravity internal 2014-05-27 15:15:57 -04:00
Jasper St. Pierre
3a0af0faae window: Add a meta_window_get_titlebar_rect 2014-05-27 15:15:56 -04:00
Jasper St. Pierre
0890eaa3fe window: Rename get_geometry to get_session_geometry 2014-05-27 15:15:56 -04:00
Jasper St. Pierre
d4058d947b window: Remove meta_window_get_rect
It's a bad API that returns weird results you wouldn't expect.
2014-05-27 15:15:41 -04:00
Jasper St. Pierre
b704659899 backend: Add an XIWarpPointer wrapper
This makes Alt+F7 / Alt+F8 work respectively under X11 nested mode.
For the native backend implementation, we'll need a special Clutter
function, so don't implement that for now.
2014-05-27 14:28:35 -04:00
Florian Müllner
0a9187a6e9 window: Add accessor method for gtk_theme_variant
This is useful information for UI associated with a window, so add
a corresponding method.

https://bugzilla.gnome.org/show_bug.cgi?id=730752
2014-05-27 19:40:06 +02:00
Florian Müllner
31db32e826 Actually implement opening the app menu
The last commit added support for the "appmenu" button in decorations,
but didn't actually implement it. Add a new MetaWindowMenuType parameter
to the show_window_menu () functions and use it to ask the compositor
to display the app menu when the new button is activated.

https://bugzilla.gnome.org/show_bug.cgi?id=730752
2014-05-27 19:40:06 +02:00
Florian Müllner
c2ea650b3c Add support for app-menu button in window decorations
We want to synchronize the button layouts of our server side
decorations and GTK+'s client side ones. However each currently
may contain buttons not supported by the other, which makes this
unnecessarily tricky.
So add support for a new "appmenu" button in the layout, to display
the fallback app menu in the decorations.

https://bugzilla.gnome.org/show_bug.cgi?id=730752
2014-05-27 19:40:05 +02:00
Jasper St. Pierre
969131f00e core: Reindent 2014-05-27 13:25:25 -04:00
Jasper St. Pierre
c98090c061 constraints: Remove improper frame_rect_to_client_rect for placement
Constriants are now in frame rect coordinates.
2014-05-26 13:27:54 -04:00
Jasper St. Pierre
3168d3b5e6 window: Move the extents storage above the rects
So all the rects are grouped together.
2014-05-24 20:47:56 -04:00
Jasper St. Pierre
efcd7d86e7 wayland: Add support for show_window_menu 2014-05-24 15:56:04 -04:00
Florian Müllner
04449923bd Remove MetaMenuIconType
Unused since 2006, quick, before we hit the 10-year mark!
2014-05-23 20:45:55 +02:00
Jasper St. Pierre
47b3336ffa monitor-manager-xrandr: Make sure to XFlush the XUngrabServer
Otherwise, the server may not receive our request, meaning that
we'll hang onto the server grab forever.
2014-05-22 17:39:46 -04:00
Jasper St. Pierre
0f37c1b58e keybindings: Replace the incomprehensible set of flags with a gravity param 2014-05-22 16:09:14 -04:00
Jasper St. Pierre
a3747725ed window-wayland: Don't use meta_window_get_position 2014-05-22 15:47:30 -04:00
Jasper St. Pierre
c448650a60 keybindings: Correct move_to_corner_backend
meta_window_get_position() returns the client rect position, which
we then pass to meta_window_move_frame. Just use the existing frame
rect coordinates.
2014-05-22 15:47:30 -04:00
Jasper St. Pierre
c45f616fdc keybindings: Fix code style 2014-05-22 15:47:30 -04:00
Jasper St. Pierre
9402691aaa window-x11: Remove a use of meta_window_get_position 2014-05-22 15:47:29 -04:00
Jasper St. Pierre
cbffbb0be0 window: Rename the requested_rect to the unconstrained_rect
The requested_rect is a strange name for it, because it's not actually
the rect that the user or client requested all the time: in the case of
a simple move or a simple resize, we calculate some of the fields
ourselves.

To the MetaWindow subclass implementations, it just means "the rect
before we constrained it", so just use the name unconstrained_rect.
This also makes it match the name of the MetaWindow field.
2014-05-22 15:39:10 -04:00
Jasper St. Pierre
9df5b17940 window: Allow passing garbage window sizes for move-only actions
We'll just fix them up in meta_window_move_resize_internal.
2014-05-22 15:39:10 -04:00