Dennis “onestone” Kasprzyk has done it again!
Ladies and Gentlemen what you are seeing here may well be the future of compiz as we know it, in a new compiz branch called compiz++ which allows for really neat things like:
– Running compiz without any opengl/composite, just like a normal WM
– Possibly an XRender backend and or clutter backend
– Decoration reparenting
— Completely reworked multi-display/screen code:
— Per screen plugin lists (e.g. cube on one screen and wall on the other)
— Rendering of one screen can not block the rendering of the other screen
— Different libGL per screen (with LD_PRELOAD)
— Simplier plugins
— Simplier option handling
– Intelligent plugin wrap/unwrapping. Now compiz can use less CPU when idling!
– Rewrite to C++:
— Smarter function callbacks with Boost (boost::function/boost::bind)
— Easier and smarter privates system (get the plugin struct for a given core struct/old FOO_SCREEN (s), FOO_WINDOW 
macros). The new system hides most of the ugly handling from a plugin developer and provides a new simple and ABI safe way to work with plugin plugins (plugins that expose features/functionality to other plugins)
— Constructors/Destructors allow easier initialisation/cleanup for a lot of systems.
— Containers avoid the implementation of lists and resizeable arrays over and over again.
— Containers like maps and other smart classes can improve performance in several areas.
— …
There are currently branches in libcompizconfig, bcop and crashhandler for this kind of work.
If this is the future (and hopefully it will be) then expect some work to halt and a lot of breakage (for now) as the team needs to port almost 100 plugins to the brand new core.
Have a good (insert holiday here)!
– Sm
EDIT: There seems to be a mixed response in the comments. This is always a good thing of course, discussion and debate is what drives progress, but here is my take on things as a developor:
C++ seems to be the most debated point here. It is a big change from a developer standpoint because it introduces it’s own limitations and oppurtunities. Personally, I don’t know much about the language, other than it is object-orientated, and it would appear that it is onestone’s favorite language (some of libcompizconfig and all of the kde-* stuff is c++ already, and to be honest, when he said to me a few months ago that his secret project was ‘more a rewrite’, I pretty much guessed that he was going to rewrite compiz in c++. I even guessed the name ‘compiz++’). I do need to stress however that this is a rewrite and not a port so I am sure that onestone has carefully thought about how compiz would fit into such.
Speed appears to be another issue, the immediate reaction was ‘C++ introduced overhead’. I guess what would need to be considered here is the other stuff ‘compiz++’ introduces, for example the intelligent wrap/unwrap system is a godsend for speed because it means that we aren’t executing code we don’t actually need to use (A lot of plugins in the paint functions get called from wrap, most of the time all they do is prepare some variables, do some boolean checks to see if they should be doing anything and then unwrap again, this would prevent that). Again, as one user said in the comments (not a direct quote) ‘It’s really all up to what functions you use’.
Lots of developers may or may not be driven away from a C++ architecture. I personally don’t know C++ (only C) as I have never felt the need to learn it now. I’ve started learning it and it’s really not all that hard from a plugin-developer standpoint, just move from setting variables directly to using the inbuilt getters and setters and using methods more etc.
Certain things will of course be different under the new architecture, I’m sure that we need to re-think a lot of our code to optimise under and object-orientated model, for example we could just create a new ‘cube’ in a plugin for some textures and use it’s methods to rotate it independently of other cubes. Or in my animation rework, we no longer need to handle all the animation tracking in animation, plugins can just create new animation objects on the fly.
Anyways thats my 2c. Onestone wanted a general agreement among developers before it goes forward and wanted to avoid any forks.
-Sm
Alternative Fax 
Hmm, well as a personal thing, I dont like the switch to c++. C is faster, and on linux, has a much more solid background with more optimizations. Also, there are people (like me), who specifically try to avoid C++ code. On smaller systems, compiling c++ code is a BEAST on your computer, especially with the Boost libraries. On my previous laptop, I could play various games such as World of Warcraft and other that are well, intensive, with no problems. However when compiling the Boost libraries or other c++ programs, I had to put my laptop on a fan so that it litterally wouldnt stall from overheating. C++ code also has more overhead than C code, even when its optimized. Objects just simply use up more memory and power than pure raw C. Therefore, I believe that this system would be even better and more put if it was done properly in C. (Besides, we have a now several year backend system that has been using C, with all our bug fixes. Why remake it in to something that in terms of technical performance, isnt as good? Its just easier to make plugins?) I’d rather have the stability and performance than millions of plugins, and so do the many of windows and mac users I know that I’m switching to linux.
Anyways, just my 2 pieces 🙂
Oooh bad news 😦
I’m not against C++ in some cases, but I really don’t think this is the right place to do it. Efficiency of operation is IMO much more important than program design neatness IMO.
I cannot put it any more eloquently than Linus did when people were asking about git and some C++ stuff:
http://thread.gmane.org/gmane.comp.version-control.git/57918
Great news!
It will be easier to create plugins. Let’s compile it 🙂
Dont know if this is good or bad…..
Can someone explain this in an user point of view?
In most cases the efficiency difference between C and C++ is negligible from an end-use vantage point (in fact C++ can actually be faster in some cases, e.g. sorting, since the compiler actually has *more* information to work with when optimizing).
Linus’ argument is basically:
1. STL and Boost are unstable and unportable.
2. Object-oriented design is inflexible.
I don’t know of any stability/portability issues with either STL or Boost, and Linus doesn’t call out any specific examples. Thus point (1) isn’t that convincing unless someone can show me otherwise.
Point (2) is also debatable. Linus seems to have a thing against any academic notion of good design, including OO. But the fact is that the Compiz design is ALREADY object-oriented internally. So if OO is inflexible then the “C” Compiz is just as screwed as the C++ branch in this regard. C++ just provides extra syntactic sugar to make the OO less awkward.
What is a valid concern is that g++ is arguably less mature than gcc. But how big of an issue is this really? KDE uses g++ for everything and I don’t see it falling flat on its face.
And just when I thought I could leave Compiz for a little while to get some of my own work done… And now I have to actually learn C++.
@ Jason:
<>
you do realize you’re comparing games (by definition, interactive processes) with source compiling (by definition a batch process) based on subjective observation,
and that, hardly anything can be inferred about the efficiency of the language they are coded in (AND the associated language runtime ), comparing the subjective “feel” of different types of programs with entirely different designs,
don’ t you?
the only way to benchmark one language against another is writing a performance critical loop encoding the SAME algorithm with the respective nominal contructs
<>
certain features of C++ impose some unavoidable overhead (but no overhead if not used – unless the compiler is pretty dumb)
and yet they may save the excessive amount of code (with a higher chance of producing intricate unmaintainable code, by the way ) to be written to reimplement them (poorly) with a more spartan language (say, if i need to reuse, or to generalize, previously written code), then the overhead may well be worth the gain
but for many others this is not the case, and the overhead, if any, depends on the quality of the implementation (compiler + runtime)
case in point, exceptions: a technique to achieve negligible overhead in handling exception chains exists, comes with a cost in the form of increased overhead should the exception actually be raised (but this is a minor issue if the exception actually is an “exceptional” event) and is widely used today (contrary to a decade ago);
or class hierarchies with single inheritance only: in this case, a smart compiler may be able to save on the cost of the vtable
<>
i dont’t think this as something a programmer could be proud of..
@ Colin:
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
this dispells all the fallacies behind the Finn’s biased reasoning more eloquently than i could do, using logic and ( programmer) common sense, recommended read
@ Will:
i was writing a (even more) lenghty reply, thanks for allowing me to save space by expressing my very thoughts in a more concise way 🙂
to add to the picture, i’d be curious to see how an LLVM compiled release of KDE would perform against the usual GCC compiled one…
@ Jason
i was referring to
Also, there are people (like me), who specifically try to avoid C++ code.
sorry for the quoting mistake
Hey guys,
A rather mixed response here, probably what I expected though.
C++ is the most debated one here. I can’t say anything for sure about onestones reasoning for it, I do know that it is his favorite language (lots of things in compiz are c++ like some of libcompzConfig kde4-window-decorator) etc. I can’t say say anything about the speed impact although I can assure you that some of the more intelligent wrap code will help with it. Having a more intelligent object orientated system forces us to re-think in the long run, for example in my animation rework it would seem more practical to just create a new animation object , functions and all for the client to handle instead of doing things internally in the animation plugin.
Also, I’m sure some of the other stuff here would have been difficult to do without it.
Personally, I don’t know c++ but I would be willing to learn considering how far forward this could take compiz.
As far as “learning” C++ for writing plugins is concerned:
1) As a person who learned C and C++ simultaniously (meaning that I mixed them in my first programs until I noticed I was writing plain C++ with some standard C functions) I kept asking myself “why didn’t they just use C++ for compiz” while trying to write plugins since all that object-oriented-programming mimicking in C is just a pain in the ass if you ask me and using C++ would make writing plugins more straight-forward…
2) If you managed to write plugins for compiz using C, I think writing them in C++ will be a piece of cake and you will end up thanking god (or whatever/whoever you prefer 😉 ) for compiz++
Of course this is just my subjective opinion and I’m far from being a specialist in programming, so I can’t really tell you about the overhead of C++ compared to C but:
1) If C++ creates overhead because of object-oriented programming – wouldn’t the chances be very high that the overhead is small compared to the overhead produced by programming object oriented code in C since C++ compilers have been there for a while and have thus been optimized?
2) on what machines is compiz running? Will it really matter?
Other than that I’m afraid chances are low for compiz++ to become the future of compiz since it seems that many compiz devs are somewhat coming from the gnome-land which kinda seems to be C-ruled – or am I wrong here?
I have to take the “not a fan of a switch to C++” side of this argument. C rocks. I always find myself spending more time arguing with the compiler and trying punch holes in my classes to get at the data I want to get to. I’ve found C++ limits transparency in code, and encourages laziness in learning exactly what’s going on under the hood.
As far as (runtime) efficiency goes, they’re about comparable. C is faster if you look at most benchmarks, but I think that a lot of the differences between C program’s speed and C++’s progam’s speed has to do with the structural choices made by C programmers versus C++ programmers. From various life experiences, I have a working theory (not disproved yet) that C++ code spends a lot more time messing with the stack then C code does.
I’m reluctant (at best) to switch languages. seems like a cleanup or even “refactoring” of what we have is better, from a project-stability standpoint, as well as a future maintainability standpoint. imo, the concept of “object oriented programming” is best if it is enforced at an architectural level in C through developer diligence, rather than at a compiler level in C++.
C is faster if you look at most benchmarks,
what benchmarks? what environment are they performed in? what compiler is used ?
without this, and taking into consideration that, e.g. GCC is known to produce better code from C rather than C++ sources, benchmarks are hardly relevant…
From various life experiences, I have a working theory (not disproved yet) that C++ code spends a lot more time messing with the stack then C code does.
i start with the assumption that the C and C++ code you’ ve looked at, do equivalent things though being written by different programmers with different coding styles, if it isnt so the point is not relevant at all
all C code that i’ve seen shows a common trait: functions are long, with more LoCs than the text rows my monitor can accomodate, most often than not – same goes for nested loops and conditional code branches
most C++ code i’ve seen otoh, breaks class methods down into smaller functions in order to keep low per method cyclomatic complexity and LoC count – my theory is that this produces an increase in stack usage and it is this you’ve seen
imo, the concept of “object oriented programming” is best if it is enforced at an architectural level in C through developer diligence, rather than at a compiler level in C++..
that would defy the very purpose of OOP – object oriented programming has been conceived to let the developer focus on modeling the problem in terms of the entities it involves and their functions , rather than on the overall instruction flow
after compiling, everything boils down to a sequential flow of (machine) instructions, obviously –
but , if a certain problem can be intrinsically modeled via objects and datatypes, then forcing oneself (and possibly others, which is even worse) to implement an object model in a plain procedural language, thinking of how it would work and writing all support code by hand ( and yet, without ever being able to achieve the most interesting features of OOP) denotes inflexibility on the programmer’s part, and inability to choose the right tool (*) for the job – thus, it’s one of the dumbest things a programmer can do imo (besides being, as others have said, a real PITA)
(*) : as more prominent professional (people from the gaming and DB industry) developers than me have often pointed out, the right tool is always the one that allows one to solve the current problem as quickly and efficiently as possible
that is not to say C++ is the perfect tool…
just a better tool for performance conscious OOP than C (btw, there exist OS kernels written in C++ – haiku being the most notable atm – and it’s only logical it can be used for system programming as C is, since it is a superset of C …), whereas java, or c# or even python are better tools for rapid application development and so on
i leave you with one example – a modeling and simulation system where any object can be made of an arbitrary number of other objects or subsurfaces (as heterogeneous as they can be – 1d, 2d, 3d or “meta” -think of modifiers – types, polygonal, analytical, subdivision, n-grade nurbs …) and ANY property can affect ANY other (maybe even physical ones) – oh, and no switch() ‘es or if chains can go in, since branches introduce a grave penalty on processors without conditional execution
in OOP it’s a relatively simple mixture of Composite and Action patterns, that can reflect one or more base classes/interfaces and a set of concrete classes that optionally aggregate other base class instances and implement specific behaviour via polymorphism and let themselves be aggregated in generic containers
but in C ?
Well, if this isn’t supported by anyone, it’ll just die off and be a waste of time. Good experiment though.
Hello, first of all I think this is really a good start for compiz.
I’m actually doing my Bachelor of Science in Switzerland and I really don’t understand why a project like Compiz still being programmed in C and not C++ the notions of classes and lots more are not so hard to understood.
Perhaps most of you shall read one or two tutorials about C++ before rejecting this project.
I totally agree with this Marco :
” (*) : as more prominent professional (people from the gaming and DB industry) developers than me have often pointed out, the right tool is always the one that allows one to solve the current problem as quickly and efficiently as possible
that is not to say C++ is the perfect tool…
just a better tool for performance conscious OOP than C (btw, there exist OS kernels written in C++ – haiku being the most notable atm – and it’s only logical it can be used for system programming as C is, since it is a superset of C …), whereas java, or c# or even python are better tools for rapid application development and so on ”
There’s a black point that really upsets me all the time with open source projects.
All people think they have the truth, but none think of what is the best for the project.
At moment there’s no equivalence to C++ modeling and coding for big projects as compiz.
Even you can create functions in C there’s no way ot organize them as good as classes etc. To make a good program you first have to think on your algorithm and on the way of doing it.
I know most programmers prefers to focus on programming and achieving their plugins or everything else as fast as possible.
Maybe shall you remember that a good programmer can adapt himself to do what is needed. Here the main idea is to cleary rewrite compiz in C++ and add in the same way some new features.
By rewriting a program you can rethink on your algorithm correct bugs that you haven’t look at before.
I don’t think a long conversation to see if yes or no C or C++ will be used.
The main post explains clearly that C++ will make things easier and better.
So why don’t change ?
It will take time ? Are you in a hurry? Is there someone who really care about this ?
You know what users want ?
Something usefull, something that works and works great.
They don’t mind if you need one year or more to do it, they just want to install their OS and imediatly start using it, if 3D acceleration is present so compiz 3D plugins will work otherwise not.
Most users really don’t care about compiz or not, most of them don’t know most of the plugins they have installed but not configured.
As I said before, we shall be able to work on any project in any language, and the main goal is to have something better and better.
I don’t think C++ will get us to compiz 0.2 again… Think on it, giving a chance to this project would be a good idea before rejecting it.
I can’t for the life of me find the code. This should be the repository, right?
http://cgit.freedesktop.org/xorg/app/compiz/
@Will
“What is a valid concern is that g++ is arguably less mature than gcc. But how big of an issue is this really? KDE uses g++ for everything and I don’t see it falling flat on its face.”
I totally agree, I think linus was on a really bad mood when he answered that.
Because he didn’t really argument enough to explain why C++ is not a good choice.
I agree with you that he don’t like the academic notion of design and OO.
I think good programers can do great things, languages used have a minor impact when they want to do great things.
C++ isn’t bad at all, the industry has proved it many times.
I don’t want pros and cons between C and C++ here, I think you should just focus on what will work better for compiz.
Well, obviously changing the programming language of the project at this stage isn’t working out great for the future.
Well, I’ll have to stand on the C++ side. Doing object oriented programming in C rather than in C++ never made much sense to me anyway. I guess one of the original reasons for using C was to allow Compiz to become a part of Xorg in the future. But that is not likely anymore, is it? I think the advantages (stated in the comments above and in Dennis’ email) of switching to C++ far outweighs the disadvantages (if any). In addition to those, with C++ more programmer errors can be caught at compile-time due to stronger typing, resulting in fewer bugs. Also, it will be easier/cleaner to block code from having access to variables that it shouldn’t have access to. This is not a bad thing at all. It’s safer and, again, will allow more problems to be caught at compile time, which would go unnoticed by the C compiler.
The still-unconvinced can have a look at this:
http://unthought.net/c++/c_vs_c++.html
and this for some performance-related info:
http://www.eventhelix.com/realtimemantra/basics/ComparingCPPAndCPerformance.htm
For me, the switch to C++ will also make it much easier and cleaner to implement some planned performance improvements for Compiz.
The only possible downside to the switch could be the time that will be needed for the conversion of plugins (well, that, and the lack of C99 designated initializers in C++, which is ok). But I don’t see spending that time as something negative, as it will allow cleaning up the code in general and possibly finding and fixing unknown bugs. The fact that contributing developers will need to learn C++ (if they don’t already know), can only be a good thing for them. It’s not that hard anyway. And we’re not rushing anything, right?
If the switch to C++ will result in smaller, cleaner, more maintainable, and more flexible code that is not necessarily slower (and in certain cases even faster with less code, e.g. by using STL containers rather than linked lists), why oppose it?
Awesome. So when can we expect Compiz++ Fusion–?
@ryzzen:
IF compiz++ gets merged (the devs are discussing it now) and when all our previous c-f work is ported. That will take a long time and during that time, we also need to re-think a lot of our previous work to make it work correctly with the compiz++ core.
Putting all performance and other issues aside for now.
Its interesting to see how most people here prefer to use a ‘easier to use language’ than one where the ‘whole’ project is already built in the current language. Users don’t care about how neat code is. They care about how well and fast it runs. Users just want something to work.
And guess what? Some people here say that people dont mind waiting for Compiz to change over to c++. Well then what about all the people using Compiz now (meaning every modern distro) including the ones provided on most netbooks and other computers finally being sold with linux on them. Those customers often came right from Windows. All they know of is how Windows works. Sure they know that Windows crashses, and its normal to them. But a not working Linux is something they are not used to, so they notice errors and slowness a lot more than on Windows. So why change something that is already working and working well just to rebuild it all from scratch with new bugs, new things to learn, new stability issues to work out, new compiler issues to work out, and worse of all…
Why was Compiz originally written in C?
The developers of Compiz KNOW C. If we switch to C++, sure, some programmers out there might be happy, like the plugin writers. But the REAL important people (no offense) is the people that make Compiz and the X11 libraries that are meant to be used better by C programs that Compiz currently uses. Those people know C, therefore they can make better code that is faster, more stable, and they can develop faster in C. If they switch to C++, they need to learn a whole new world. It’s like switching from a Plumber to a Doctor for a job.
As for the gcc and g++ thing…
You most certainly can not say that for performance you are not allowed to compare the compiled code of gcc and g++ (meaning gcc produces better computer code). The fact for us linux users is that GCC and G++ ARE the STANDARDS for compiling. Therefore they are our life and give life to our programs. If two libraries come out that do the same thing, but one is faster and better than the other, which do you use? Obviously the better one. You use what is best. GCC is better. The reason KDE uses G++ is because from the start a LOOONG time ago they used C++, which can only be done in g++.
This Compiz++ thing is, sorry to say, as it was pointed out before anyways, just a programmer who’s favourite language is C++ trying to get the project he is working on in to his language of choice.
Don’t you think there is a reason ‘all’ major OSes use C for programming? Possibly? Either way, we’ll see what happens when some more stable and ready version of Compiz++ come out. That will be a decent benchmark for C vs C++.
@Jason
Nobody said the language transition process would be smooth sailing. In fact, this is the ONLY legit reason not to use the C++ branch (but admittedly, a major one). I’m just saying that there is no *technological* argument against C++. So the real question is not “will this affect users?” but rather “is the transition pain worth it for the maintainability benefit gained from using C++?”
“If two libraries come out that do the same thing, but one is faster and better than the other, which do you use?”
The problem with your analogy here is that gcc and g++ do NOT do the same thing. One compiles C, the other C++. That’s a world of difference. The point is that g++ gives us a language with many benefits, and the “faster and better” difference between compilers might be too small to matter.
“Don’t you think there is a reason ‘all’ major OSes use C for programming?”
Yes: UNIX and POSIX are strongly tied to C for historical reasons. This pretty much covers all major OSes except for Windows. And we all know what a lovely track record Windows has. 🙂 More seriously though, I’d be willing to bet that C++ (the compilers and the language itself) wasn’t mature enough at the time these major systems got their start — 20-30 years ago is a LOONG time in the software world. Things have changed.
@Marco
Little side note: Haiku (and BeOS) indeed use the C++ for the kit implementations and APIs. But the kernel proper is still implemented in C. I remember reading on their mailing list that they probably would have chosen to implement the kernel in C++ had NewOS (the kernel they forked) not already been written in C.
Is this work based on the much talked about object frame for compiz by David Reveman if so onestone completed it ?
@Will
i was really sure i had seen a bunch of .cpp files, with many containing classes and object method invocations, last time i checked – yet, it may be i only looked at files (under the VM and IO management sections) coincidentally added or rewritten after the NewOS import…
oh well, i guess i’ll have to check again -better- asap… 🙂
i quote you by word on the rest 😉
This whole “how much kernels are written in C”-argument doesn’t make sense because A KERNEL IS A KERNEL and not a window manager like compiz… Parts of the kernel are written in assembler but this doesn’t mean any programs a user uses should be written in assembler as well…
I suggest you read this: http://www.tux.org/lkml/#s15-3 – especially ADB’s comment…
@Marco
Hmm, you are right. I haven’t checked the codebase in awhile… looks like C++ has made it into the kernel after all. 🙂
@gahre
Agreed. Kernels were just brought up in the context of efficiency, since they have a particularly extreme design constraint in that regard.
> I cannot put it any more eloquently than Linus did when people were asking about git and some C++ stuff:
>
> http://thread.gmane.org/gmane.comp.version-control.git/57918
That’s fucking hilarious, we should start calling you Lolin from now on. Linus’s answer there contains not one iota of eloquence, it’s just a bigoted, fanatical, religiously inspired rant, and the fact that you think otherwise proves that you’re just as much of a fundie as he is.
And by the way, “Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C” may be a jolly good fun thing to say when the C++ programmer in question is some random unknown peon, but when he’s an established, influential developer on the project already, it’s really not the best way to get people to respect your opinions.
@sol0matrix:
No. The problem with O-F is that it had little documentation and remained inactive for quite some period of time.
I also fear that this might be the case for compiz++ too, no documentation will come out and it doesn’t look like the branch is going to get much attention.
For those who are worried that this might put compiz into an alpha state, this was already discussed on the mailing list, here is the thread.
http://lists.freedesktop.org/archives/compiz/2008-December/003231.html
I’ve been following CF developement since it was born. I’m not a programmer even if I know a little C and C++.
Let me get this straight: I don’t think this is is going to be good for Compiz future. Even if a complete rewrite would actually make Compiz better (and I’m not really sure of) it still remains a HUGE work. Most of compiz programmers is struggling with work/studies and play with compiz as a free time hobby…
I’m really afraid this whole thing is going to die really soon, leaving both compiz and compiz++ alone. At least now we have something that works! (and isn’t too bad).
I really hope I’m wrong… 😦
@Gianpa:
If this goes ahead, I would think that we would maintain a 0.9.x branch and 0.8.x branch for a while until there are no feature regressions in 0.9.x at which point we start bugfixing and heading towards 1.0 IF this gets merged
C-like languages are such a joke. There is only one language, I’d do this is: OCaml! Allows for compilation (speed between C++ and C), bytecode (speed between Java and C++), and interpretation (faster than any of the big scripting languages).
It allows object orientation, but you don’t have to use it. It’s functional, strongly typed, and overall has tons of features to make working it it fun. It also is much more stable, because you won’t be able to compile it if it could crash! (Except for the C-interface of course. Go figure…)
And of course there are libraries for OpenGT, SDL, and so on. 😀
Eclipse supports it now. too.
Oops. I meant OpenGL, of course. :=
Wake up all at Compiz as Beryl is alive and kicking !
You might be interested that over a weekend a mate and myself introduced Beryl back in to the fold. This is a direct result of our frustration of how bloated Compiz has become and is becoming more of a fashion thing rather than functional for having multiple desktops.
OK so I have been using Ubuntu 7.04 on and off for a couple of years now and Beryl comes as default. After Ubuntu 7.04 Compiz Fusion (now Compiz) came as default. To begin with this was not a problem but as Compiz became more complex with spheres, globes and other useless features, performance was becoming impaired.
Late one night I started looking at introducing Beryl to Ubuntu 9.04 (Alpha 6). As expected there were numerous depedendency issues.
Piratesmack looked in to the same possibilty and together we pooled our resources and after running many scripts and testing by myself Piratesmack compiled some dependency free deb. packages.
Piratesmacks Beryl 0.2.1 deb. packages for Ubuntu 9.04
http://files.filefront.com/beryl+fixed+904tarbz2/;13596520;/fileinfo.html
Save to home directory
extract tar.bz2
cd beryl-fixed-9.04
sudo ./install.sh
Piratesmacks Beryl 0.2.1 deb. packages for Ubuntu/Mint
http://files.filefront.com/beryl+packages+021tarbz2/;13508777;/fileinfo.html
Save to home directory
extract tar.bz2
cd beryl-packages-0.2.1
sudo dpkg -i *.deb
Beryl 0.2.1 on Ubuntu 9.04
Beryl 0.2.1 on Mint 6
One thing you cannot do is knock the simplicity of Beryl and how much more useful it is than modern day Compiz.
So for those who wish to mock I say Beryl is far from dead and people want it as they are downloading it for the very reasons I have outlined above.
LUg.