Commit Graph

6980 Commits

Author SHA1 Message Date
Adel Gadllah
6eeaf09ab7 compositor: Don't call process_damage if the window is gone
We might get a damage event for an already unmanaged window calling
process_damage is pointless and causes a crash so simply skip that case.

https://bugzilla.gnome.org/show_bug.cgi?id=727115
2014-03-27 14:06:27 +01:00
Jasper St. Pierre
f93fa1d705 window-actor: Don't queue a redraw when queueing a new pixmap
We guarantee ourselves that a valid pixmap will appear any time
that the window is painted. The window actor will be scheduled
for a repaint if it's added / removed from the scene graph, like
during construction, if the size changes, or if we receive damage,
which are the existing use cases where this function is called.

So, I can't see any reason that we queue a redraw in here.

With the split into surface actors, we don't have an easy place
we can use to queue a redraw, and since it's unnecessary, we can
just drop it on the floor.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-03-26 17:30:46 -04:00
Jasper St. Pierre
cd905a34fb compositor: Kill off MetaCompScreen
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.

We still keep MetaScreen in the public compositor API for compatibility
purposes.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
47aa583625 display: Kill off grab_screen
Just like active_screen, the screen can always be inferred
from the MetaDisplay, so there's no point in keeping it around.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
d7519f4ebc Remove any possibility for zaphod mode
We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.

With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.

We also kill off active_screen at the same time, since it's
not necessary anymore.

A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
97ea4e8717 xwayland: Remove some stray logs
These really aren't too helpful.
2014-03-26 12:04:14 -04:00
Jasper St. Pierre
208296a619 wayland: Shut up about Setenv if we're past initialization
I'm a bit tired of hearing about this when I launch mutter-wayland
nested. Ideally, this would be part of display server integration,
not GNOME integration, so we could simply not make the call when
nested, but oh well.
2014-03-26 12:02:08 -04:00
Jasper St. Pierre
cc0488f1e2 surface-actor: Implement is_argb32 generically for both X11 and Wayland
cogl_texture_get_components can be used on both X11 and Wayland
backends. Technically, the detection is different: we actually
check the actual RENDER format in the old code, while Cogl simply
assumes that any pixmap with a depth >= 32 is ARGB32. Since Cogl
already seems to be working with its internal checks, it makes
more sense to  use Cogl's check rather than keeping our own.
2014-03-25 17:04:39 -04:00
Jasper St. Pierre
e30ed6892c surface-actor: Prevent a dumb crash
is_argb32 can be called at any time, including times when we don't
have a texture. In that case, just assume we're ARGB32. The value
really shouldn't be important though.
2014-03-25 17:04:37 -04:00
Jasper St. Pierre
d699b2409a xwayland: Shut up conditionally 2014-03-25 12:54:13 -04:00
Jasper St. Pierre
ef65848d11 window-wayland: Implement kill 2014-03-25 12:05:21 -04:00
Jasper St. Pierre
272676b896 surface-actor-wayland: Make sure to clean up on dispose
We need to remove our destroy handler if the surface is destroyed
before the buffer is, which is the case when we have no destroy
effect.
2014-03-25 12:00:38 -04:00
Jasper St. Pierre
44580ddb80 wayland-surface: Unref the buffer after removing the destroy listener 2014-03-25 12:00:38 -04:00
Jasper St. Pierre
456e3e2429 xwayland: Punt stdout / stderr to /dev/null
This should really go to the journal, but I'm tired of seeing Xorg
log a bunch of garbage that I don't care about when debugging mutter.
2014-03-25 12:00:38 -04:00
Florian Müllner
eba848e8aa Bump version to 3.12.0
Update NEWS.
2014-03-25 16:33:00 +01:00
Florian Müllner
71be7e8493 display: Fix compiler warning
Don't leave a variable uninitialized in case we don't find a matching
surface.
2014-03-25 16:32:22 +01:00
Florian Müllner
a742b17805 Bump version to 3.12.0
Update NEWS.
2014-03-25 16:25:28 +01:00
Rui Matos
7484d540cd wayland: Use an array initializer for the X server arguments
This fixes the unitialized array members introduced previously and
should avoid such mistakes again going forward.

https://bugzilla.gnome.org/show_bug.cgi?id=727011
2014-03-25 14:52:57 +01:00
Ray Strode
a55622d924 wayland: drop -logfile argument
It breaks testing wayland with setuid X server.
2014-03-24 14:18:49 -04:00
Petr Kovar
c4b65e0e6e Update Czech translation 2014-03-22 20:49:28 +01:00
Daniel Korostil
9ec8232417 Updated Ukrainian translation 2014-03-22 12:18:24 +02:00
Andika Triwidada
768e830f11 Updated Indonesian translation 2014-03-21 10:42:48 +00:00
Мирослав Николић
4a4a624b77 Updated Serbian translation 2014-03-21 03:06:38 +01:00
Jasper St. Pierre
1cfaf45389 surface-actor-wayland: Fix meta_surface_actor_wayland_is_argb32
This prevents us from clipping shadows under windows for all
apps, and loads of other fun optimizations.
2014-03-20 18:03:38 -04:00
Jasper St. Pierre
42491f7724 window: Actually interpret the FRAME_SHAPE_CHANGED result
When I refactored this out into a vfunc, I forgot to change the
code that interprets the result flags to actually respect the
new FRAME_SHAPE_CHANGED result flag.

Since we weren't ever clearing the frame bounds, this meant that
the "shadow clip" wasn't ever updated as a result. Since right now
all Wayland surfaces are considered ARGB32, we always clip shadows
under frames, and thus shadows had this weird "punch-out" from the
first frame shape.
2014-03-20 18:03:35 -04:00
Jasper St. Pierre
9696e785da screen: Remove flash_window
It's unused as well
2014-03-20 16:48:15 -04:00
Jasper St. Pierre
0de83ebfb5 display: Remove get_leader_window
It's unused.
2014-03-20 16:46:21 -04:00
Jasper St. Pierre
337db2a660 window: Kill off the rest of colormaps
I removed the XInstallColormap / XUninstallColormap but forgot
to remove the fields in MetaWindow and the code to set them.
2014-03-20 16:27:22 -04:00
Jasper St. Pierre
054c307353 window: Remove support for colormaps
While the ICCCM mandates the use of this, it's not necessary under
a composited environment from my understanding, and it's a flat
out no-op under XWayland.

Looking at the other rootless servers like Xwin/Xquartz, it seems
that they contain code for colormap emulation, but they're actually
never used -- a bug prevents the code from ever being called. Given
that it's been this way since 2003, I'm going to hazard a guess that
not many apps using colormaps. Kill them off.
2014-03-20 16:25:09 -04:00
Jasper St. Pierre
852589897e Move send_icccm_message to window-x11 2014-03-20 16:22:15 -04:00
Jasper St. Pierre
46b4d6c0f0 Move request_take_focus to window-x11
This will let us kill off send_icccm_message
2014-03-20 16:06:24 -04:00
Jasper St. Pierre
ab2224686a events: Clean up trailing whitespace 2014-03-20 15:54:16 -04:00
Jasper St. Pierre
24b08d1a36 Move event handling to a new file
display.c is getting a bit crowded. Move most of the handling
out to another file, events.c.

The long-term goal is to have generic event handling here, with
backend-specific handling for the types of windows and such.
2014-03-20 15:46:32 -04:00
Jasper St. Pierre
0808adefaf Move focus to be a vfunc 2014-03-20 15:20:15 -04:00
Jasper St. Pierre
14f424cd02 Move ping to be a vfunc 2014-03-20 15:20:15 -04:00
Jasper St. Pierre
9debd2fb0d Move delete / kill to be a vfunc 2014-03-20 15:07:44 -04:00
Jasper St. Pierre
57359da9b4 wayland: Kill the buffer destroy error
Previously, a sequence like this would crash a client:

  => surface.attach(buffer)
  => buffer.destroy()

The correct behavior is to wait until we release the buffer before
destroying it.

  => surface.attach(buffer)
  => surface.attach(buffer2)
  <= buffer.release()
  => buffer.destroy()

The protocol upstream says that "the surface contents are undefined"
in a case like this. Personally, I think that this is broken behavior
and no client should ever do it, so I explicitly killed any client
that tried to do this.

But unfortunately, as we're all well aware, XWayland does this.
Rather than wait for XWayland to be fixed, let's just allow this.

Technically, since we always copy SHM buffers into GL textures, we
could release the buffer as soon as the Cogl texture is made.

Since we do this copy, the semantics we apply are that the texture is
"frozen" in time until another newer buffer is attached. For simple
clients that simply abort on exit and don't wait for the buffer event
anyhow, this has the added bonus that we'll get nice destroy animations.
2014-03-20 13:53:05 -04:00
Jasper St. Pierre
e67abdd3ff compositor: Kill unused variable 2014-03-20 13:18:55 -04:00
Jasper St. Pierre
ca4777f778 compositor: Make code a bit more understandable 2014-03-20 13:18:47 -04:00
Rui Matos
76dc0ca681 wayland: Exempt CLICKING grab ops when syncing wayland input focus
If we have a CLICKING grab op we still need to send events to xwayland
so that we get them back for gtk+ to process thus we can't steer
wayland input focus away from it.

https://bugzilla.gnome.org/show_bug.cgi?id=726123
2014-03-20 17:08:53 +01:00
Rui Matos
8968501031 wayland-seat: Don't send pointer enter/leave events during a GRAB_OP
meta_wayland_seat_repick() can be called in various cases while mutter
has a GRAB_OP ongoing which means we could be sending wrong pointer
enter/leave events.

https://bugzilla.gnome.org/show_bug.cgi?id=726123
2014-03-20 17:08:53 +01:00
Rui Matos
1b29113150 wayland: Set/unset wayland focus on mutter grab/ungrab operations
This ensures that we send the proper leave and enter events to wayland
clients.

Particularly, this solves a bug in SSD xwayland windows where clicking
and dragging on the title bar to move the window only works on the odd
turn (unless the pointer moves away from the title bar between
tries). This happens because xwayland gets a button press but doesn't
see the release so when it gets the next button press it discards it
because its pointer button tracking logic says that the button is
already pressed. Sending the proper wayland pointer leave event fixes
it since wayland clients must forget about button state at that point.

https://bugzilla.gnome.org/show_bug.cgi?id=726123
2014-03-20 17:08:53 +01:00
Jasper St. Pierre
15c59f9919 keybindings: Split out check for filter_keybinding
This is a small code cleanup for clarity.
2014-03-20 11:03:54 -04:00
Jasper St. Pierre
a53e094fcd window: Move move_resize_internal logic to protocol-specific directories 2014-03-20 11:02:50 -04:00
Jasper St. Pierre
a377a1a110 window: Move client-type-specific managing / unmanaging to a vfunc 2014-03-20 10:51:32 -04:00
Jasper St. Pierre
74a1e00e30 window: MetaWindow is now abstract 2014-03-20 10:50:27 -04:00
Jasper St. Pierre
1c41f71eef window: Add a type for Wayland windows 2014-03-20 10:50:27 -04:00
Jasper St. Pierre
63350c52cc window: Remove code for static gravity resizes
It was never turned on for all the years it's been there.
2014-03-20 10:50:27 -04:00
Ask H. Larsen
b13b7ea72e Updated Danish translation 2014-03-19 22:33:10 +01:00
Florian Müllner
9a89cc1198 Bump version to 3.11.92
Update NEWS.
2014-03-19 21:26:42 +01:00