[Compcomm] Things to do, the state of the merge

[Kristian Lyngstøl]

Since there is a lot of negativity floating... Please avoid flaming in
this thread, if you feel some of these things need to be discussed,
start a seperate thread. I'd like to use this thread to help people
get a grasp of what actually CODING can be done right now. How you can
contribute. I fear we are loosing developers because of the bickering
this merge is causing, and that's not good. I know I myself lost a lot
of motivation, and that I'm not alone. So let's get some work-items
out there. Most of us are in it for the fun of working on something
that makes progress, so let's make progress.

Right now, what I as a former Beryl developer consider the biggest
holdup for me using Compiz, is the situation with settings. As I
understand it, we're missing python bindings in libbs, but are
otherwise looking good? Is there any major work items left here? How
about beryl-settings (no discussion of wether we'll use it here
please, just wether it's ported)?

As for multihead, we're discussion the perspective-situation on the
Compiz ML awaiting some final decisions there. If David is ok with it,
it'll take me about an hour, or less, to re-implement the projection
matrix code I wrote for Beryl, in Compiz. I have a few multiscreen
patches pending, but more will be written.

For multiscreen, we still need to make the manager multi-screen aware.
beryl-manager only starts one decorator, where it needs to start one
per head. I'll also suggest a more CLI-based manager, which also takes
care of system checks and offers the most frequently used options as
defaults in stand-alone installations. Anyone feel like looking into
that?

I don't know the state of all the plugins, I saw Danny write a short
summary, so I'll assume most of it is under control.

One issue I personally wouldn't mind someone picking up is window
restraining at startup. I'm using the wall plugin with 6x6 viewports
at the moment, and whenever I start it, my windows will be restrained
to the first N viewports. Danny mentioned this is because of the
initial state of s->hsize/vsize. Shouldn't be too hard to figure out.

Does anyone have any other merge-related work items that doesn't spike
too much discussion? Or maybe just something they would like to see
fixed. I think this is probably a good time, to let us coders focus on
something besides the flaming.

-- 
Regards,
Kristian