Robert, yes... That's the fix (as always the one-line changers are the ones involved in tricky cases like this one).
I've written a little on the merge proposal, but that stateChangeNotify call causes unity to readd the decorations to the window (since when there are none when maximized), and thus to request the window to be resized to occupy the space = workspace - windows extents size. What basically happens in a buggy state is: 1. Compiz tells the window to unmaximize 2. Unity tells the window to resize to cover the maximized are + decorations 3. Window restores, going back to the old geometries, and notifies compiz 3. Compiz receives the notification from the window with the new geometries 4. Compiz confirms the new restored geometries sending them back to the window. However, while point 2. is the one causing problems the fact is that some windows (g-t, emacs: probably the ones with embedded widgets which take more to resize) seem to ignore the new correct geometries that we send back to the window, we basically send two events almost together and the 2nd one seems to be discarded by these. Now, inverting points 2. and 1. we avoid sending to the window to use a maximized space after that we said that we want it restored. All this is quite racey, and I still have some doubt about some gtk3 involvement, since while it's true we're sending them confusing stuff, they shouldn't ignore our last request. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1521302 Title: gnome-terminal maximize than un-maximize behaves odd To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1521302/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
