lp:~vanvugt/compiz-plugins-main/fix-1084386

Created by Daniel van Vugt on 2012-11-29 and last modified on 2012-11-29
Get this branch:
bzr branch lp:~vanvugt/compiz-plugins-main/fix-1084386
Only Daniel van Vugt can upload to this branch. If you are Daniel van Vugt please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Daniel van Vugt
Project:
Compiz Main Plugins
Status:
Merged

Recent revisions

36. By Daniel van Vugt on 2012-11-29

Quick fix for build failure (can't find compiz_core during linking).
(LP: #1084386)

This fix is intentionally self-contained in compiz-plugins-main. A proper
fix to core is in progress in bug 1084386.

35. By Sam Spilsbury on 2012-11-29

Avoid a crash caused by the fix for bug 755842. (LP: #1015151)

34. By G. Uitslag <email address hidden> on 2012-07-12

Using the next/previous bindings the wall plugin didn't calculate correctly
the next workspace when it reaches the begin or the end of a row of
workspaces, so it didn't jump to the next line. (LP: #904205)

32. By Sam Spilsbury on 2012-05-09

If a window spanned two monitors it would shift around on viewport changes.
Take all workareas into account when calculating window shift. (LP: #755842)

31. By Daniel van Vugt on 2012-04-27

Set VERSION to 0.9.7.3 until we have a candidate for 0.9.7.4

30. By Daniel van Vugt on 2012-04-24

Prepare to release compiz-plugins-main 0.9.7.2

29. By Daniel van Vugt on 2012-04-24

Change the mouse pointer while dragging windows in expo. Just like the
ubuntu branches do. (LP: #987647)

28. By micove on 2012-04-24

Fix exec_prefix in some of the pc files. (LP: #959260)
---
Add missing library links. (LP: #959260)
I checked the buildlogs and found:
dpkg-shlibdeps: warning: debian/compiz-fusion-plugins-main/usr/lib/x86_64-linux-gnu/compiz/libwall.so
contains an unresolvable reference to symbol dlopen: it's probably a plugin.

dpkg-shlibdeps assumes that the program that loads the plugins provides these
symbols therefore not giving an error.

[Miguel Colon <email address hidden>, 2012-03-14]

27. By Sam Spilsbury on 2012-04-10

Don't increment the destroy ref count of a window unless an animation is
active. (LP: #940603)

It doesn't make any sense to increase the destroy reference count of a window
on CompWindowNotifyBeforeDestroy based on whether or not an an animation for
that window "could" be allowed - CompWindowNotifyBeforeDestroyed is called
on CompWindow::destroy (which under sane circumstances, should only ever be
called when the window is either reparented away from its parent or the root
window or when the window is destroyed).

In this case, we deregister all events on the window so it isn't possible to
determine through any normal means that a close animation is going to activate
on the window. And in any event, the unmap which causes close animations
always comes before the DestroyNotify or ReparentNotify anyways.

Even if the CompWindowNotifyClose were to somehow come after the window
received a ReparentNotify or DestroyNotify, the tradeoff then comes between
not playing animations for those corner case windows or keeping ghost windows
on screen because we kept a destroy reference and never got rid of it. In this
case, it is more sane to do the former.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:compiz-plugins-main
This branch contains Public information 
Everyone can see this information.

Subscribers