Bug Description

Binary package hint: compiz

In the current version of compiz in Natty (beta 1), the dbus-plugin doesn't work. If inspected with d-feet, the org.freedesktop.compiz entry exists, but contains no methods and attributes. Compiz itself is working fine.

Most of the broken features are not essential for this plugin to be useful.

The list method is the most important but not essential since the object paths are always constructed with same pattern: /org/freedesktop/compiz/*plugin*/screen0/*option_name*. You don't need the list method to find the object path.

Plugin metadata is not that useful unless you are building a compiz setting editor and don't want to use python and compizconfig. Introspection is just a nice addition - not critical to the usage of dbus plugin.

The API was updated. You need to s/allscreens/screen0/ . Also a lot of
the list and introspection stuff is not yet implemented since there
was no time to do it in the rewrite. This is an area for which
somebody could contribute if they are interested.

On Sun, May 1, 2011 at 11:59 PM, pauljohn32 <email address hidden> wrote:
> I would have said this bug is so serious that the release of Natty
> should have been blocked by it. A non-functioning window manager is a
> BIG thing, not ignorable.
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/749084
>
> Title:
> Dbus-Plugin of compiz not working
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

It is enough. The introspection stuff has not been rewritten for 0.9.x
since I had no time to do it, that's why methods don't show up in
dbus-tool

On Thu, May 12, 2011 at 12:45 AM, Mario Kemper (Romario)
<email address hidden> wrote:
> I don't believe it is enough to s/allscreens/screen0/. As Johannes
> wrote, if you inspect the bus with a dbus-tool, the
> org.freedesktop.compiz entry exists, but contains no methods and
> attributes.
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/749084
>
> Title:
> Dbus-Plugin of compiz not working
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

I was always using screen0 and
dbus-send --print-reply --dest=org.freedesktop.compiz /org/freedesktop/compiz/obs/screen0/brightness_values org.freedesktop.compiz.set array:int32:80
doesn't work. If no introspection, Is there any up-to-date documentation or working examples?

Same problem for me if I try to enable Compiz plugins by using DBus!
This is how to reproduce my bug: simply launch this command:
$ dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/core/screen0/active_plugins org.freedesktop.compiz.set array:string:'dbus','decoration','place'

Note that I've no problem to receive the list in C or with this command:
$ dbus-send --type=method_call --print-reply --dest=org.freedesktop.compiz /org/freedesktop/compiz/core/screen0/active_plugins org.freedesktop.compiz.get

Precise here and loads of error messages.
I think it should be _very_ important to get the whole dbus backend work, because Unity looks great and is very good to use, but since things don't work under the hood, users can run into problems.
I doubt I could help as I know only some basic python, but if I can, please let me know, I'd like to have this problem fixed asap.

If we break functionality of a plugin and we know it is not working anymore at all or just producing errors (like currently dbus, td, session for example) what is the point of shipping it ?
Either we should fix it or not ship it to the user, otherwise this just has the potential to frustrate the user !

It is quite a shame that this bug is *Reported on 2011-04-03* but still we ship this completely broken plugin that is just plain useless for everyone... :(

Most of the broken features are not essential for this plugin to be useful.

The list method is the most important but not essential since the object paths are always constructed with same pattern: /org/freedesktop/compiz/*plugin*/screen0/*option_name*. You don't need the list method to find the object path.

Plugin metadata is not that useful unless you are building a compiz setting editor and don't want to use python and compizconfig. Introspection is just a nice addition - not critical to the usage of dbus plugin.

These should, of course, be fixed but the situation is not so bad this bug implies.

[ Łukasz 'sil2100' Zemczak ]
* Remove debian/patches/unity_support_test.patch:
- Running the support test from compiz has bad side effects, from now
on we run it from Xsession.d
* Automatic snapshot from revision 3644

[ Nikolay Martynov ]
* When static switcher is enabled and has an option to show
application icon turned on the icons are expected to be ~1/3 of a
thumbnail (48px). Instead they are displayed in 512px size and
completely cover everything. This change addresses this issue. See
LP #1173914. (LP: #1173914, #1186426)

[ Brandon Schaefer ]
* Unrevert 3728, fix failing tests. Change the behaviour of
undecorating windows. Previously when a window was undecorated, we
would shift it back to an appropriate position according to its
gravity member. That behaviour was problematic because in the
StaticGravity case the window has to just stay in the same place.
But then if you had a window with StaticGravity which then did get a
decoration and later removed it, it would be placed as though it was
decorated and appear to be in the wrong place. The correct behaviour
is to place all windows as though they have decorations, and then
when decorations are removed, to move the window back to the corner
as indicated in its gravity and then expand its size to cover the
obscured regions no longer hidden because the decorations went away.
(LP: #1165343). 1. Completely remove decorOffsetMove and other
related code from decor.cpp. Put the logic to handle the
window->input () - window->border () placement offset inside of
setWindowFrameExtents instead. Now the window will always be
offset from its original non-decorated position to the new
decorated position, rather than having to guess between
decoration sizes. 2. Make saveGeometry and restoreGeometry work
relative to window->border () a...