Merge lp:~townsend/unity/fix-extra-decorations into lp:unity/5.0

Proposed by Christopher Townsend on 2013-07-04
Status: Merged
Merged at revision: 2422
Proposed branch: lp:~townsend/unity/fix-extra-decorations
Merge into: lp:unity/5.0
Diff against target: 12 lines (+1/-1)
1 file modified
plugins/unityshell/src/PluginAdapter.cpp (+1/-1)
To merge this branch: bzr merge lp:~townsend/unity/fix-extra-decorations
Reviewer Review Type Date Requested Status
Unity Team 2013-07-04 Pending
Review via email: mp+173027@code.launchpad.net

Commit message

Check to see if the window is supposed to have decorations instead of the window actually being decorated when Undecorate() is called. This fixes a race condition where windows opened maximized upon login would sometimes have extra decorations.

Description of the change

= Issue =

When using Unity 5.20 in precise-proposed, a new bug would sometimes occur if you have an application start up maximized when logging in. This is due to lp:unity/5.0 revno. 2415.

= Fix =

Check to see if the window is supposed to have decorations instead of the window actually being decorated when Undecorate() is called. This fixes a race condition where windows opened maximized upon login would sometimes have extra decorations.

To post a comment you must log in.
Marco Trevisan (TreviƱo) (3v1n0) wrote :

It seems that the same code is also in trunk, do we have the same bug in saucy?
If yes we should probably propose for it before.

However, why not keeping IsWindowDecorated inside Undecorate and modifying it so that it returns immediately false if HasWindowDecorations returns false (if doing this we should probably think also to a way to optimize the calls, so that we reduce to the minimum the GetMwnDecorations [i.e. XGetWindowProperty] calls)?

Christopher Townsend (townsend) wrote :

@ Marco,

Yes, the same code is in trunk, but I cannot reproduce the issue in Raring or Saucy. I don't know for sure, but I think those releases handle opening maximized windows upon log in differently or the race condition either do3es not exist or is mitigated by something else.

As far as keeping IsWindowDecorated and optimizing the calls, since this only seems to affect Precise, why not just leave the MP the way it is? Do you see some downside to that?

Timo Jyrinki (timo-jyrinki) wrote :

Well hmm this was already released to precise in 5.20-0ubuntu2. So it should definitely be in the 5.0 branch as well.

Timo Jyrinki (timo-jyrinki) wrote :

It then needs to be reverted for the next SRU if wanted.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'plugins/unityshell/src/PluginAdapter.cpp'
2--- plugins/unityshell/src/PluginAdapter.cpp 2013-03-18 21:20:01 +0000
3+++ plugins/unityshell/src/PluginAdapter.cpp 2013-07-04 13:48:32 +0000
4@@ -1118,7 +1118,7 @@
5 void
6 PluginAdapter::Undecorate(guint32 xid)
7 {
8- if (!IsWindowDecorated(xid))
9+ if (!HasWindowDecorations(xid))
10 return;
11
12 MotifWmHints hints = { 0 };

Subscribers

People subscribed via source and target branches