Compiz 0.9.2 Is On The Way

[phoronix]

Phoronix: Compiz 0.9.2 Is On The Way

One of the Compiz developers has updated his blog about the ongoing work towards the Compiz 0.9.2 release now that Compiz 0.9 was finally released earlier this month...

http://www.phoronix.com/vr.php?view=ODQ0Ng

[allquixotic]

...Sound?

1. It's a compositing manager! That's for graphics. When did sound enter into the picture?! Your desktop / session manager handles that, or even individual apps -- right?

2. Why (just) ALSA? If you're too timid to write a PulseAudio client, at least use OpenAL -- that basically allows you to avoid the problem of having users debate the merits of various sound APIs to you, because chances are fairly good (especially now with OpenAL-soft looking up) that whatever sound backend your users are using, OpenAL has a configuration that works for them. Plus, you could work 3d positional sounds into it, using OpenAL's API, so you can hear sounds coming from various areas on the surface of your desktop cube. That would be cool, but still -- it's not the job of the compositing manager, I think.

The unfortunate part about compiz supporting sound is that you end up adding to the overlap between various parts of the desktop. If every part of the desktop tries to encroach a little outside of its core territory, you end up with chaos: two or more different programs (mutually unaware of what the other is doing) trying to perform similar or identical functions. Not only is this frustrating for the user, but it can result in incorrect functionality, such as two sounds playing from two different programs when an event occurs.

I think compiz should expose a lightweight external interface that sends position data and event metadata whenever an event occurs that would demand a sound effect. You could have a thread in the desktop or session manager do blocking reads on a UNIX pipe, and have compiz write to it with a pre-determined data structure to define something like, "event of type W<string> at (X<int>,Y<int>) on desktop surface #Z<int>". That's just how it would be pretty-printed; the actual data format could just be a serialized representation of a struct.

By sending plain ol' data to the desktop and allowing the desktop to decide what to do with the data (visual cues? sound? logging? other uses?), it would be much more flexible than implementing sounds in compiz.

I haven't checked, but if compiz already has an external interface of a similar design that would effectively trigger whenever the desired "compiz sound effects" would occur, then the sound effects thing is already completely redundant.

[etnlWings]

The unfortunate part about compiz supporting sound is that you end up adding to the overlap between various parts of the desktop. If every part of the desktop tries to encroach a little outside of its core territory, you end up with chaos: two or more different programs (mutually unaware of what the other is doing) trying to perform similar or identical functions. Not only is this frustrating for the user, but it can result in incorrect functionality, such as two sounds playing from two different programs when an event occurs.

Well that seems like a pretty minor issue. I can't really imagine libcanberra sounds for GTK+ widgets, having much to do with window manager sound events. If we're talking about one sound event when 'a programme is started' and another when 'a window is opened', it would almost appear that the libcanberra-based sound events would be the ones encroaching upon the window manager's territory.

That said, one of the first things I do on any OS is disable system sounds. I'll also grant you that it's just messy but without some concerted effort between the major projects, I don't see much of a solution.

I haven't checked, but if compiz already has an external interface of a similar design that would effectively trigger whenever the desired "compiz sound effects" would occur, then the sound effects thing is already completely redundant.

Compiz has a Dbus plugin. I have no idea what it's used for but it's there, if they wanted to pass sound effects off to an external daemon.

[V!NCENT]

No pulseaudio means not being able to individualy control the Compiz volume, which is totaly lame.

And mousetrails? What's that? Windows 95? Yeah I'll tell them. Oh yeah Windows 95 wants its mousetrail effect back.

[etnlWings]

I'd say mouse trails could be really helpful. 'Could', in the sense that they look nothing like the way Windows does them to this very day. Short 'glowing' trails would be welcome on my 1920x1080 monitor, where I don't want to use a giant mouse cursor but I also don't like trying to locate my mouse - especially when there's a lot of white on the screen.

[sylware]

if compiz is C++-->switch to mutter.
if compiz is C -->I shall give it a try.

[curaga]

I'd say mouse trails could be really helpful. 'Could', in the sense that they look nothing like the way Windows does them to this very day. Short 'glowing' trails would be welcome on my 1920x1080 monitor, where I don't want to use a giant mouse cursor but I also don't like trying to locate my mouse - especially when there's a lot of white on the screen.

They should do a plugin that would make the cursor glow on a key combo. :P

[etnlWings]

Assuming you're not being sarcastic, they already have a plugin for that.

[V!NCENT]

What do some people have against c++? It's just a language that is like C but can do more if desired. It can lead to way more beautiful and efficient code. It is not slower perse, espcialy not if one considders the simple fact that speed is in the algorithms and not so much the speed of the binary excecution. For example assembly can run 10 times faster while a better algorithm and operators can result in being 100 times faster. What a bunch of BS...

[nanonyme]

at least use OpenAL

Seconded. Go for OpenAL.