Support client-side window decorations (I can see two title bars for GTK on Mir)

Bug #1398849 reported by desrt on 2014-12-03
66
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Undecided
Unassigned
Mir
Triaged
Medium
Unassigned
gtk+3.0 (Ubuntu)
Medium
Unassigned
mir (Ubuntu)
Medium
Unassigned
qtmir (Ubuntu)
Medium
Unassigned
unity8 (Ubuntu)
Undecided
Unassigned

Bug Description

I can't find a way for telling Mir that we have decorations drawn client-side and the result is that we have two sets of decorations (and shadows) when running Gtk applications under the demo server.

It would be nice if we could tell the display server that we are drawing the decorations.

Also up for discussion: if the client is going to be drawing the shadows then we also need a "frame extents" sort of mechanism that we can use to tell Mir how large the shadows are. This needs to be compensated for when performing various window management tasks (eg: snap to edge).

kevin gunn (kgunn72) wrote :

this is an important item, but it may be a while before we're in a position to give window decorations devoted engineering/implementation attention.

also, worth reading is
https://docs.google.com/a/canonical.com/document/d/1tVSQmWNGLto5-JyVLzjTD0OLSJ7PMA9ckuL5GfEfSfo/edit#heading=h.dt1zhfihm6rz

which outlines how the system & apps will cooperate when it comes to system side vs client side decoration

Daniel van Vugt (vanvugt) wrote :

I've started work on this and you can see evidence of it in the Mir server code. Presently the client dimensions == extents but in future they will be different.

tags: added: enhancement
Changed in mir:
importance: Undecided → Wishlist
status: New → Triaged

Per the duplicate bug we should probably use mir_surface_type_freestyle

Changed in gtk+3.0 (Ubuntu):
importance: Undecided → Wishlist
summary: - support client-side window decorations
+ support client-side window decorations (GTK on Mir)
Changed in gtk+3.0 (Ubuntu):
status: New → Triaged
tags: added: snappyrdp
Daniel van Vugt (vanvugt) wrote :

Also, I think we should not be supporting or encouraging client-drawn shadows. They do create the edge placement extents problem mentioned in the description, but also result in an inconsistent look to the overall desktop. I think even if a client provides its own "decoration", that should not include shadows. The shell should be in charge of shadows so that they all appear consistent and seamless (if present at all).

As for what to do about odd-shaped surfaces with an alpha channel, I know generating a shadow for those is not efficient and needs to not be recalculated on every frame. I suggest that following the surface's input region shape is best there, or to add a client function to notify the server of shape changes (roll it in with resizing?).

Robert Ancell (robert-ancell) wrote :

Client side decorations will also require movement being initiated from inside the surface (bug 1420334)

summary: - support client-side window decorations (GTK on Mir)
+ Support client-side window decorations (I can see two title bars for GTK
+ on Mir)

Alan Griffiths have start the work on the fix for https://bugs.launchpad.net/mir/+bug/1420334 ,This is required to support full client-side decoration

Any news?

Changed in qtmir (Ubuntu):
importance: Undecided → Medium
Changed in gtk+3.0 (Ubuntu):
importance: Wishlist → Medium
Changed in mir:
importance: Wishlist → Medium
Changed in qtmir (Ubuntu):
status: New → Triaged
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity8 (Ubuntu):
status: New → Confirmed
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers