Kristian’s look on things

After a lot of back and forth, some fumbling with a vote and a lot of suggestions, we finally managed to find a name. Compiz Fusion. There are a lot of people relieved that we finally managed to find a name. Myself included.

We ended up weighing developer/contributer opinions higher than the users in this specific issue, after all, this is our work we’re naming. But the process was made in such a way that we found a name that the most developers didn’t dislike. Sort of the opposite of a vote for a winner. The plan was to have the users decide between the remaining names, but in the end, there wasn’t really any names remaining.

Personally, I’m very happy with this method. I never thought it would take this much effort to find a name, but the users should know that we spent a lot of time on finding this name, and every imaginable option was explored. There were a lot of concerns we had to honor: We didn’t want a name that was a “morf” between Beryl and Compiz (Like Coryl, and many also felt Coral was just this). We also had to honor the wishes of the people who will work most with the name.

There are still a lot of things we need to decide, and it’s not easy. There are still many hot debates going on, or that will have to be started. We need to decided what to do with forums, domain names and whatnot. Besides that, we have to find a more permanent way to manage the project.

Code-wise, we’re going forward, luckily. So most of this is tiresome squabbling. But we still have to deal with it, and there are some issues with how we’ve worked on code too. Many of us feel we need a more proper planning phase for the development process, this is specially true for the settings system, which was developed by a close group of former Beryl developers. This isn’t something unique to the Compiz Fusion project though, we kinda wanted to do that in the Beryl Project too, and many of us feel it’s a valid point in the Compiz development cycle too.

Now that we have a name, packagers are getting to work. Guillaume (iXce) and Alex (nesl247) on the Beryl side of things are sorting out git-renaming (yet again) and forum work, Dennis (onestone) seems to be doing the build-tuneups, and all of will probably adjust our individual code bits to fit to the new name. Because I tend to stay away from the longer arguments on the mailinglist, I haven’t really spoken to Rico lately, but I hope he can get to work too, even if he’s not exactly best friends with all the other developers and contributors at the moment.

So, for those who’re confused:

Compiz - The original project. Now only the core and a select few original plugins, located at freedesktop.org and the main developer is still David Reveman.

Beryl - A discontinued fork of Compiz, after “compiz-quinn”, a community set of patches, had drifted too far apart from the original project. Introduced many features, both in the core and outside. And attracted many developers. And the fork it self was the source of much debate.

Compiz Extras - A sort of “division” consisting of the people who worked on compiz, but the extras were not core-fixes. The concept is similar to what made Beryl what it is, but also very different. It was to include a wider set of plugins and tools. Now discontinued.

Opencompositing - A common name used for the merged project and more, does not include the core. This was meant mostly as a temporary name, but what becomes of this terms has yet to be decided. It will most likely be dropped.

CompComm - Another name for the merged project, not including core, more of a shorthand for “Compiz Community”. The opencompositing.org git repositories sported compcomm/ prefixes, this was mostly done for practical reasons. This name will be discontinued entirely.

Compiz Fusion - A community project forged by the merge between the Compiz Extras and the Beryl project. This does NOT include a core, as the core changes in Beryl are either being scrapped, or re-written for the core Compiz project. Compiz Fusion will sport settings tools, more plugins, helpfull scripts to start Compiz with the Compiz Fusion plugins, and basicly anything related to Compiz that’s not the core.

Beryl and Compiz is merging. Compiz will remain the name for the core. For everything else we need a new name.

There’s currently a poll on the opencompositing.org forum.

There is also a lot of complaints on how this is done. Some people don’t like one name for whatever reason, others do. Some people feel they weren’t heard and their alternative should be on the vote. Many people calling for stopping the vote.

Well, as it happens, I’m all for democracy, but this is ridiculous. The people who should be responsible for naming a project, is the creators of the project. Not everyone and their dog. And we can’t wait around forever for a name. The name is important, but it’s even more important that we get one, and fast.

Personally, I voted for Coral. I’m not particularly happy with it, but in my opinion, it’s a name most people can accept. I don’t care that there are other projects with similar names. Coral is something growing in the sea, that’s where it’s from, not “stolen”. And I don’t think discussing names for a few more months is going to yield any happy results.

I am amazed by how many opinions everyone suddenly has on a decision on the name. It doesn’t change anything, except it allows us to FINALLY get a web page, wiki and more with the proper branding. I urge the people who are giving their opinions on this to think twice. We want a name, we want to hear what people have to say, but in that order.

As for claims of lack of information, that’s utter rubbish. No, we did not advertise this in your local newspaper, but the fact that we needed a new name has been well known since we started talking about a merge. The vote has also been somewhat discussed on the “compcomm” mailinglist, and there was a thread on the forum prior to putting up the post. And names like Coral, CoCo and Blitz were suggested long before the vote came up for discussion, and they have been loosely discussed among the developers. If anyone has strong feelings about this project, they’ll know how to find this information. If anything, the problem with opencompositing.org is that there is too much discussion going on, it takes forever to make any sort of decision.

There are also a lot of helpful individuals wanting to give input on how the project is steered. We do have a lack of leadership. There are two communities in play here, and neither wants the other to “take over”, thus making it difficult to find a leader we can all agree on. But it’s not like we actually need one. The Beryl project had Quinn as a leader, but in reality, she did not try to steer us. So far, we’re working on separate parts, and then there are individual leaders for each “sub project”. These are not announced as leaders, it’s just the natural way of working: Whoever works most on a project, is the one people talk to about it.

We will be working on non-developer teams soon. We’ve already put together a support team for the forum, which seems to work well (These guys deserve their own tribute-post, but that’s for a later date). When we have a name, we need wiki and web focus too.

What concerns me is the low and often negative participation in this joint effort from (former) members of the compiz community. It is not strange that opencompositing resembles the Beryl project, when all the input we get from the Compiz community is that it’s a silly idea and that we should just stop and do what the compiz community guys did before the merge (which I personally don’t think was much). I beg these individuals (you know who you are) to sign up on the opencompositing.org forum, send ideas instead of criticism to the compcomm list and help us! We can’t create a merged project if only one party has their heart in it.

I for one don’t WANT a new Beryl project. I liked the beryl project, but it’s time to move on. We can’t do that without new ideas. But let’s talk about what to do, instead of talking about what not to do.

One day I’m writing about all these changes I want to make in Beryl, and the next day Beryl is merging with the Compiz community. So whatever happened to my vision? Was it just talk? No, it wasn’t.

There were a few improvements made to the Beryl core. I consider the idea behind the “Beryl logger” important; It made debugging a lot easier. It will also help new developers, and track strange bugs that the development team can’t reproduce. It helps to increase the understanding of how Compiz works.

I also started cleaning the event code. Splitting it up. I spent a great deal of time experimenting to find out what really had to be inline and what didn’t. Looking back, I wouldn’t want the current state of the Beryl event code to be released as a stable release, but I think it’s the right way to go. The changes I made were not bad, but it wasn’t finished.

So far, these changes has not been merged. I belive what I did with Beryl in this area gave at least myself some important experience on the real flow of the code. I hope to use this to eventually improve the Compiz core too.

A few people seem to have misunderstood my ideas though. I belive David’s overall design is pretty sound, but I’m just not happy with the state of the code and the lack of documentation.

Instead of trying to explain what has been explaind countless times before, let me quote Chapter 6 of the Kernel’s CodingStyle Document, I’m sure you can find similar explanations in any document that deals with C coding style.

Chapter 6: Functions

Functions should be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80×24,
as we all know), and do one thing and do that well.

The maximum length of a function is inversely proportional to the
complexity and indentation level of that function. So, if you have a
conceptually simple function that is just one long (but simple)
case-statement, where you have to do lots of small things for a lot of
different cases, it’s OK to have a longer function.

However, if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you think
it’s performance-critical, and it will probably do a better job of it
than you would have done).

Another measure of the function is the number of local variables. They
shouldn’t exceed 5-10, or you’re doing something wrong. Re-think the
function, and split it into smaller pieces. A human brain can
generally easily keep track of about 7 different things, anything more
and it gets confused. You know you’re brilliant, but maybe you’d like
to understand what you did 2 weeks from now.

So what’s next? I’m not sure I’ll be working too much on the Compiz core in the immediate future. A few multihead related things, but nothing major. I do have my zoom project to consider, after all. I hope I can get back to my original plans eventually.

As for the future of Beryl, we’ll continue to support the stable Beryl branch (Beryl 0.2.x) for some time. This means critical bug fixes to keep it running, and user-support to a certain degree. When we’re ready to release something under the “opencompositing.org” brand (No, we don’t have a name yet… sigh), I figure we’ll stop supporting installation-problems with Beryl from sources other than official packages bundled with distributions.

After a little bit of hacking, I’ve got the original compiz plugin working with input enabled. Since the plugin doesn’t get MotionNotify events when input isn’t grabbed, it has to fetch the motion from other places though. So far I’ve solved this by fetching in DonePaintScreen() which works very well for me, but both common sense and early reports indicate that it’s not enough. The result is a little choppy.

The solution should be fairly simple. Either just add it to a timeout, which is what Beryl’s inputzoom plugin does, or… Ok, I guess that’s the only real option I can come up with, except modifying core.

In addition to enabeling input, I’ve also gotten basic focus tracking up. This is by no means well-implemented yet, nor am I satisfied with it. There’s two major issues:

• It’s simply annoying.
• The function for setting the zoom area to a specific area is bugged

The first problem is a fundamental problem that will probably take a lot of tweaking. So far I’ve added a hardcoded delay (which will be configurable soon) in when to activate focus tracking. This helps avoid jumping around when sloppy focus changes the focus, as focus tracking won’t do anything if the mouse has recently moved. This is a fairly reasonable way of doing things, that I’m happy with. I also intend to add a few other mechanism for making the focus tracking more natural. The lack of input transformation really underlines this problem too, since the mouse pointer will jump whenever the zoom area is moved. However, if input transformation was implemented, it would be trivial to disable this mouse wrapping.

As for the bugged zoom area function, that’s another story. Basicly, I’ve come to the conclusion that I can’t actually do math while sitting in front of a computer. Right now, the function works after a fashion, for the first zoom level it’s also precise. For any other zoom levels, it misses a little bit. This is what I’ll be working on next.

I still haven’t decided wether this will be an entirely new plugin, or to attempt to get it accepted into the compiz core package. Since it will eventually rely on AT-SPI, I am not sure it makes sense to attempt to get it into the core compiz package, and this is exactly what opencompositing.org is for, anyway. Either way, it’ll be easily available to anyone wanting to use it.

As a last note, I’ve set up a launchpad project for google summer of code. So far I haven’t actually started using it, but I intend to use it. You can find it at https://launchpad.net/compiz-zoom.

Recently, Guillaume (Known to most as iXce) and myself got accepted by Ubuntu to work on Compiz/Beryl in Google’s Summer of Code program. I’m thrilled myself, and can barely wait to get started.

We’ll both be working on accessibility features, Guillaume on color filtering and I’ll be focusing on zoom enhancements. As the situation with Beryl’s input zoom is a bit dodgy, one of my main goals will be to both provide input enabled zoom with the current technologies, and prepare for the future with input transformation. Some of the main new features to look forward to will be:

• Zoom follows cursosr
• Zoom follows focus
• Fit zoom to window
• Fit window to zoom

The idea is to make this as generic as possible, so there won’t be a need to implement major changes when input transformation is available to most users, and ideally it should work both with and without input transformation even when it is available. This will mean I’ll probably write a new plugin, which isn’t really all that much work. I’ll be using some of the existing accessibility technologies available, but still want this to work for users that otherwise don’t have to use accessibility technologies.

It’ll be interesting working on this, but it has also been interesting in a very diffrent way to see this merge between the Compiz community and Beryl. I don’t want to spark up any new flames here, there are enough of them allready, but I hope we can get something presentable out to our users soon, but it’s not looking too good. The work on core is going quite well, and there hasn’t really been any plugin issues either, it’s everything else that is causing delays. And I also belive this is causing us to loose a lot of development time. I know I haven’t been very active myself, though I’ve done a little work on porting/merging my multiscreen stuff.

I’ve been putting together a compiz-manager script which is far from finished, which I hope can help people start Compiz in their favorite way, autodetecting many of the options that Beryl does in core, but compiz doesn’t. Beyond that, I also intend to get a build-script out there for users wanting to use the git versions, but don’t know where to begin. I’m more or less just waiting for bset to get to a point where I’m happy with it, and you would be too.

My last post kinda looks strange with the merge going on, but at least something big is happening, and we’re going somewhere.

There have been a lot of discussions lately about the future of Beryl, and our relationship to Compiz.

Let me just start this by saying that I appreciate the work David has done, and continues to do with both Compiz and now X.org. He has an immense amount of knowledge, and he is responsible for getting us where we are today with a proper composite window manager. And he keeps giving to the community through is code. For that, I thank him. I do not belive, at this point, that anyone on the Beryl team has that same amount of knowledge of X and related libraries.

Beryl is very much a direct result of his work. We are gratefull for that.

So why the fork? So far there isn’t really a significant difference between Beryl and Compiz, so did we do it just to further our careers? Did we do it because we want the glory? Did we do it out of ignorance? Did we do it because we prefer IRC over mail? Well, I wasn’t on the team at the time of the fork, I was, however, a user of Compiz, and a user of compiz-quinn. And I have been a member of the free software community since 1999, and I am a true beliver. I have also been programming since 1992. At which point I was 9. I have not been directly involved in free software as a developer on some elses project until I started working on Beryl. So what do I know?

Well, I am a purist. My code is probably far from perfect, but I want it to be in all possible ways. I strive to master whatever I spend my time on. And I love knowledge, and I respect it. But I also realise knowledge is not everything. Attitude is just as important. Where would the free software community be without the attitude of the folks who started it all? Nowhere.

This brings us to the core of what I personally consider the main reason why a fork was necesarry. Attitude. Compiz is developed as a one-man project, and that could be a good thing, but it would require that it is done because of an attitude. Not because it is convenient. If the code was clean and smooth, I would surely have no problem understanding why someone would want complete control over every part of it. They would want to make sure it remains clean. However, this is not the case with the compiz code, nor is it the case with the Beryl code. There are som ingenious solutions in Compiz and Beryl, but the implementation is not pretty. There are functions that makes you forget C is a procedural language half way through reading them, it looks more like a dirty script. And these are central and crucial parts of the code.

When you add to the mix that this code is virtually undocumented, and only one person really knows what the code does, you have a problem. Sure, it’s free software so you can read the code and EVENTUALLY you’ll figure out how it works, but we all know “it was tough to write so it should be tough to read” is an example of a bad attitude. A really good programmer documents his code, because he knows it will help him in the long run. It’s not just a way of helping others, it’s about helping yourself. Because if you document your code, others will help you improve it, and thus, you help yourself.

Getting back to the core issue: How does this affect Beryl?

What I want to do with Beryl is clean it up. Make it better. I want to use the good ideas David had, and implement them properly. Make the code sustainable over time. Open it up to other developers who might not have the entire day to decode a single function. I want to increase the flexibility of the code, and make it more robust.

And I intend to do that. It takes time, however. And I can’t spend all my time working on Beryl, I have school and other projects going on too that requires my attention. And I want to do it right, and to do it right, I have to cooperate with my teammates. Luckily, trunk has been unlocked, and we’ve slowly started. We are trying to reach an agreement on what specificly we want to do. We all know we want to clean up, but that’s not really specific enough.

I belive that the Beryl 0.2.0 release will not make or break Beryl. Surely there will be flames and rants about how good/bad it is, all depending on who’s writing. But in the end, I don’t belive it matters. The real work will happen in 0.3.x and the future releases. If people still sais compiz/beryl in the same breath by the time we release 0.6.0 for instance, then I’ll be worried. Right now, I say let people criticise us all they want. The Beryl team gets blamed for a lot of things we are innocent of and some things we are guilty of, but what will that matter if it turns out to be a great thing in the end? We get blamed for lying, stealing and beeing unethical. We also get blamed for what others say about us. If someone sais that beryl is more innovative than Compiz, then suddenly Beryl are the bad guys for creating a false impression of Compiz. I don’t want to say wether we’re more innovative or not than Compiz. David, surely does some amazing things that I’m gratefull for, like working on input redirection in X.org. So far, Beryl has mostly focused on Beryl. Our plugins haven’t been that radical and most of them will still work on Compiz. So no, we’re not really that much better yet, are we?

I can understand when others question the reason for our existence, but I say give us time. So far, we’ve mostly worked on getting our act together and cleaning up our OWN code, and getting some structure in the project. We haven’t even started with the real fun. It takes time to get to know the source code of a program, at least a couple of months if it’s big. We’ve finally had that time, and I at least finally feel confident when working on core. I can start doing what I set out to do.

So please, flame my comments, but remember: Rome wasn’t built in one day, just like Beryl won’t be built in one stable release.

We’ve finally gotten 0.2.0rc1 out the door and branched 0.2. Though this doesn’t mean work on 0.2 has stopped, it does mean that the freeze on trunk is over and we can start breaking things again. The first thing I’m gonna break is most likely multihead support. Or rather, the first thing I’ll start working on. While Beryl has what I would call a very good support for xinerama-hinted multihead, the more traditional multiscreen support has received more or less no work, and is, at the moment, non-functional.

I reckon it will take anything from a day to a couple of weeks to get it in a state where I can actually use it without beeing annoyed by it. Luckily, the basic framework has been there for as long as I can remember, but I doubt many of the developers realise what it’s for or how to use it properly.

Other developers (Robert comes to mind) have started looking at things like plane-replacements (The “wall” plugin), WRAP/UNWRAP and other things. We still haven’t put up a real roadmap for 0.3.x though, but hopefully we’ll get one soon.

On an other note, I’ll be at Linuxforum 2007 in Denmark in march, talking about Beryl, so if you’re in the area, grab a ticket and drop by. There are some interesting speakers on the program besides me too, so it promises to be an interesting weekend.

Ok, so we tried arranging a bug squashing weekend and we did get a noticeable ammount of bugs squashed, but the turnout wasn’t quite as good as we had hoped for. We fixed a few tickets, closed a few invalid ones, classified a few and got more assigned. We might do this again in the future though, but for more than just a few hours on a saturday.

It became more and more obvious that we would have to delay 0.1.5 a day or two, for a couple of reasons. One of them is trailfocus 2, which strictly speaking would be trailfocus 3. It’s a complete rewrite from scratch of trailfocus motivated by the excessive CPU usage of the trailfocus that lie in trunk at the moment. It did, however, revive a discussion I had with onestone at the time I wrote opacify about methods of changing paint attributes. Basicly, we both agree there needs to be a proper way of doing it, but we’ve yet to agree on what way we should do it. See http://lists.beryl-project.org for the discussion details. (dev-list)

The idea is to make it easier for plugins to deal with opacity-changes(or saturation/brightness) in a natural way. So far, there hasn’t been much of a standard, I went a bit against the wind with opacify to avoid having to calculate opacity on every paintWindow, which is how it is done on the old trailfocus-rewrite. We hope to also agree on a solution to make it easy and natural for state to override paint-changes (like exclude windows from opacify or trailfocus)

A few other reasons for the delay is snap and awaiting a unified decision on thumbnail2. Strictly speaking we’re beyond a new plugin freeze, but snap is a release criteria for 0.2.0 so that has been known all along, and there are compelling arguments for thumbnails2 too. Either way, 0.1.5 will be important, and the feedback we get from it will be vital for the quality of 0.2.0.

I’ve allways liked helping people over the net, when I’m bored I tend to fallback to that behavior and find somewhere I can be assist others. Since my involvement with Beryl, this has meant I’ve been helping a lot of people on IRC and the forum, answering on large amounts of threads and questions with what I hope is techincal insight.

This has also lead me to realise that we need to improve the FAQ, Documentation, suggestion/wishlist and  trac work. There are fa too many similar bugs, threads and whatnot. I know racarr recently posted a blog about what’s feasable and not (we spoke about it on IRC before he did this), and I’ve also started to update the FAQ section of the forum whenever possible.

I’m also trying to involve more developers in this, but for this to happen properly there needs to be a little bit of self constrain on what people post. The forum is too high traffic and too much duplication and general crazyness… I’m not telling people not to post crazy ideas, I just hope they will read the new FAQ section first. Also the threads run wild sometimes… I think that the main reason for a lack of developer involvement (there are a few of us reading the forum and the ideas do eventually reach us, but hardly everyone follows the forum…) is that us devs tend to get bored with what to us might seem like silly or trivial problems.

The solution to this is of course to make the documentation good enough for there not to be any trivial and silly posts. And then there’s the wiki… I suspect this is an area that can be greatly improved. The information probably changes regularly and I can’t remember the last time I personally used anything there. I don’t even find it trustworthy to be honest. Too many third-party repositories… It essentialy needs some attention, preferably from someone highly experienced with Beryl.

So anyway, these are just a few late-night rambelings of a much too tierd monkey, I’ve set myself a informal goal though: to climb down from the number 2 spot on the “post count” list of the forum. When my input is no longer necesarry is when I’m going to be happy

I’ve been spending my time working on the bug known as “The OpenOffice bug” lately. About a week now I guess. It’s a bug where OpenOffice windows open maximized and stay that way, including the dialog boxes. This happens semi-randomly or not at all.

Initially I wasn’t going to look at it because I can’t reproduce the problem myself, but as the community grew more and more impatient and it became apparant that non of the devs had this issue and the time to work on it, I ended up grabbing it…

So how do you debug something you can’t reproduce and that isn’t obvious and is semi-random? Why, you write a debug plugin.

It quickly proved usefull as pichalsi (and a few others, thanks to all of you) gave me feedback. It became obvious that w->type was set to 0×8000 when the windows bugged, and w->type 0×40 when they didn’t. At the same time, w->wmType was allways 0×40. The sizeHints were correct, but any other value representing the window size were wrong (maximized).

Ok, so what did THAT mean? Well, this is where 2+2=5 comes into the picture. I spent about 5 days imagining that 0×8000 was 1