Compiz is useful to a lot of people. With KDE 4 it got competition of course, so less people will be using it from now on and its devs might feel like users are abandoning it. If they can manage to shift the current nature of Compiz - an experimental playground for effects with much overkill - into a stable, functional, well behaving and well integrated window manager, then I'm sure Compiz will have a long healthy life.
If the current state of Compiz doesn't change however, then I guess interest will continue dropping and lead to the project's death. Compiz needs someone to work on the boring stuff to achieve the aforementioned stuff. Coding effects and optimizing them sure is interesting. Coding the integration parts along with testing and debugging is not, but someone has to do it, or else :P
xfwm already has a composition manager. Metacity is the only one out, but I think there are plans for one in the future. [...]
Metacity does have a compositing manager, it was added in 2.22.
It's "only" xrender based, similar to xfwm if I'm not mistaken. There are however ongoing experiments to create a gl-based compositor using Clutter and Metacity, usually refered to as "Mutter". If this will be merged into Metacity proper, or only used in Gnome-Shell I don't know.
I am currently using the metacity compositor (it isn't enabled by default, so it takes a setting in gconf to turn it on). I vastly prefer it to compiz!
Honestly, I think the problem with compiz is that it was a tech demo with usablity and user-interface, let alone well-documented code, as an afterthought. An application can get away with that for a time, as people marvel at the new technology, but ultimately it becomes clear that the application, while impressive, lacks elegence and is gaudy and impractical in its design.
I think compiz falls into this category, and the technology-centered mentallity is something they will have to combat to remain relevant. Fancy effects do not a good window manager make, ask Vista users. Compiz needs to make performance, stablity, and especially ease-of-use primary goals and relegate the technical flourishes to the status of icing-on-the-cake. Their history and philosophy so far, however, do them no great credit to that end. I think it might even be a good idea to rename the project to reflect the change in goals, for it to be more user-centric.
Last edited by TechMage89; 12-31-2008 at 11:03 PM.
What I find disturbing about the whole thing is that a window manager seems to get more attention then actual applications do. Eyecandy does nothing when it comes to making up for the lack of application development or actual functionality. Yes there is a lot of applications out there for linux but very few that actually are full featured or even remotely complete. Eyecandy may draw the n00bs in, but you have to have the apps to have them stay.
compiz was doomed from the beginning with its gconf crap. Then came beryl and made compiz bearable. But at one point I realized that wobbling windows and spinning cubes do not make the desktop better. And even transparency gets in my way way too often. Today I am using kde 4.2-svn. Effects are off most of the time - and when I use them the only usefull feature is scaling and video preview in the thumbnails
Compiz has changed window management on *nix forever so even if the project can't reinvent itself, it's not as if the death of compiz is necessarily going to be the death of the functionality or effects it's given users.
My personal preference - while perhaps unrealistic - would be for compiz to become a generic architecture with an API that other window managers could utilise.
Basic window management and desirable behaviour has never been compiz's strength so this would give users the more refined and flexible approach of using their window manager of choice, which could utilise compiz in much the same way xfwm4 and metacity utilise xcompmgr. Meanwhile, the focus of the compiz project could be on stability*, compatibility** and in developing a more user-friendly way for users to selectively choose effects/functions plugins (to use a strained analogy - like in, "the fire fox").
Another advantage of compiz becoming essentially invisible is more than just other window managers could take advantage of the API: gnome-panel, xfce4-panel and plasma could provide access to functionality in the humble form of buttons, liberating me at least from either having to use cryptic keyboard shortcuts or a 'hot corner', just to access the functionality I've enabled.
* **granted, much of compiz's stability relies on everything from x.org, the video drivers and the graphic libraries.
Frankly, I'd be happy if xfwm4 could just do the shift-switch, scale, expo and wall plugins. They're about the only plugins I use, anyway.
Seems to me that Compiz's biggest "problem" right now is that it works fine for most people today and there are no obvious "next steps" other than the big scary ones (see below). Many of the major obstacles holding back wider use of Compiz (eg. flickering 3D) need to be fixed in other areas of the stack, ie there isn't anything for the Compiz devs to do about them. Same for improving integration -- that is arguably something to be done in other projects, not in Compiz itself.
Developers are just as likely to be drifting off because there is nothing obvious to work on rather than because of a fundamental problem with the project.
One of the big questions that needs to be worked out is exactly how video playback should be handled in a compositing environment. There seems to be general consensus that sync-to-refresh should be implemented in Compiz rather than further up the stack, and that some kind of flow control should be used so that video player apps (or any animated app, I guess, including games) can match their rate of frame creation to the refresh rate, but that's as far as it goes.
Nasty scenarios like displaying 24p video on a 72 Hz display (or a 60 Hz display) need to be considered here, and there are relatively few developers who are sufficiently familiar with all the areas to make the next round of design decisions on their own.
In other words, things will probably drift until the next X developers summit