I think it is fairly obvious at this point onwards that as a project in itself, its no longer viable to continue development of compiz. Lots of people still use it though, so its is worth maintaining for those that use it, but nothing more than that.
I’m going to write this blog post with that assumption in mind.
Looking forward to a post-X11 world, and a post-desktop world in the near future, I’ve been personally questioning the need for yet another window manager and system compositor. With wayland, we are lucky in that right now that we only have weston as the more or less de-facto compositor and window manager. This means that we don’t have to worry about messy specifications on how things should work, but instead we just have an interface that exists in the code between the window manager and the clients.
The natural assumption made these days seems to be that as X11 is going away (eventually), we should “port” to wayland, by abstracting away X11 and wayland behind a common interface and then eventually transitioning over. How exactly would this be done? There are two ways I can think of: the first would be implementing a new wl_compositor, which means that you need to take care of the operating system interfaces for initializing an opengl context on a surface provided by the operating system (in the case of linux, by KMS), and then you need to take care of managing graphics buffers provided by the operating system (linux: GBM, android: gralloc). You also have to take care of handling display modes, display rotation, etc etc. The second would be implementing wl_shell, and only one wl_shell can be active at a time.
What does compiz actually provide to users of these systems? As a developer, I might tell you this:
- C++ interfaces around some common OpenGL concepts (vertex buffer objects, framebuffer objects, frame timing etc)
- An option system
- A plugin system with a chained dispatch of callbacks
- A window manager that supports reparenting
But a user might tell you this:
- State transition animations
- Virtual desktops on a cube
- The ability to paint fire on the screen
- A graphical window picker
None of this functionality that user wants really depends on our compositing engine. There’s nothing so special about our compositing engine that gives it a reason to exist. We don’t need another “window manager” that does exactly the same thing as every other “window manager” just to get this functionality which is unique to the project.
One thing I’ve learned over all my time maintaining compiz for Ubuntu and Unity is that getting a compositing engine and window manager right is very difficult. There are a lot of corner cases that you need to consider, graphics drivers that don’t quite work right, opengl generally being painful to work with. While I was at Canonical, 98% of my effort was dedicated towards maintaining the compositing engine and window manager, and 2% of my effort was spent on delivering new functionality. Its a really big job looking for a reason to exist.
This is the real practical toll of fragmentation amongst the linux ecosystem. Its not just that there are multiple implementations of the wheel. There are multiple implementations of entire cars which do almost the same thing, but a little different from everyone else. Some say this is the free software’s greatest strength. Now that I know the personal and technical toll of fragmentation, I see it as its greatest weakness.
Reimplementing an entire compositing engine and window manager just to get the functionality that people liked in compiz doesn’t make any sense. I cannot, in good conscience, continue a project in such a direction that would add more fragmentation to the ecosystem, and potentially see new developers pitted against each other.
As such, I do not have any plans to “port” compiz, the project, to wayland, and I won’t advocate for anyone else to do it that way.
What I can get behind, however is an effort to bring the functionality that people loved, to frameworks that already exist. That means more people working together, and less effort duplicated.
I used to think that one of free software’s greatest attributes was that projects outlive maintainers and codebases. I was wrong.
Free software’s greatest attribute is that codebases transcend projects.
The beauty of free software is that it is never truly “finished” and is always an open ended piece of art. When a maintainer moves on from a project, the tools to continue the development are left behind for others, and new maintainers can either choose to continue the project, or re-use parts of it in new projects.
To me, this is an admission that I believe our current way of doing things is inefficient and too competitive. Someone’s gotta give, so be a part of the change you want to see.
Let’s work together and make something amazing.
Alternative Fax 
As a non developer my opinion might be needless, but I have asked myself this question quite often, not especially in the case of opensource software, but more general. I still attend school but took a job as software developer into account, but when I look at what is going on with some opensource projects, I am not quite sure if I really want to be part of this. Things almost never complete, get redone very often or often get obsolete before they are complete. There seems to be nothing remaining in that job. You do things, but even if they continue to get used, sooner or later they get ported and after a few years there is nothing more left, than your idea and the fact that you have done something once for the project. There are not much projects like TeX.
The only thing that seems to remain are new ideas and concepts, the really important thing about software development in my opinion. From that point of view I can see your point. It does not make sense to redo things. But I thought compiz is now a par with all the other window managers like kwin and mutter? Do you think generally porting for wayland is not useful, or do you think in the case of compiz it is not useful (because the other projects like mutter and kwin already do so or want to do so? or because of the lack of developers?)
Compiz is really tied to you, now after all the work you want to give up completely? It always depends on your point of view: Compiz was there before most of the other projects now being worked on were there. So maybe they started redoing things? And if you give up compiz now and redo the things people liked about compiz you also redo something already existing.
afaik Sam didn’t start compiz, it was a Novell project in the beginning. The good news with FOSS projects is that there’s always the possibility there that someone adopts it.
Sam spent some years with it, now he wants to cut off (maybe just a little bit, maybe forever – in the end it’s his decision and an important one, too).
I don’t get the part of “there is nothing more left, than your idea and the fact that you have done something once for the project”. What do you expect? Eternal Fame? That the project remains yours forever?
I don’t know if you are really just clueless/ignorant or just trolling but I’ll bite. Things almost never complete? What about Linux, Xorg, gnome, apache, tomcat, and every single piece of code that makes up a distro. All those not complete?
You are still in school, how do you think you will get hired and get well paid after you finish school? By writing open source code and putting it out there, employers can see how good you are. I got my first job because I had created a php website and was posting tutorial about linux back when PHP still stood for “personal home pages”
I have been using Compiz for a long time. If Sam did not do anything we would never have had compiz. If it was not opensource, I would not have any code to look at and learn from. Sam might stop working on it now but others can build upon the lessons learned from it.
You miss the point that in opensource, a lot of us do things because we enjoy it. Today I was implementing a download accelerator in python. Sure there are a lot of it out there already but I want to do it for myself, and I don’t care if I am redoing something that already exists. I am going to learn from it, and hey just maybe it will be better that whats out there already. And if others want to use it, they can pull it from github later on. If I dont complete it, at least I would have learnt from it.
I’d say that the projects you mentioned are remnants of a better age, pre dotcom bubble making everyone into developer. Linux got Linus to rant at every idiot who thinks breaking user space is “okay”. X11 was done as multi vendor standard before recently getting butchered. Apache started as a series of patches to an existing project and got traction back when Linux was getting started, so it supports posix, not a bunch of mayfly apis with no single definition. Gnome is pretty hermetic project that is heavily involved in breaking and fragmenting Unix for last few years (personally I dropped it with 2.4 when it was getting obvious that everything was to be “good defaults given to you, ignorant user, by benevolent developer). Tomcat lives and dies by adhering to java specs.
Meanwhile, random, badly defined, incomplete, often broken by design apis and projects rise and fall in so-called modern desktop environments, always incompatible, rarely coherent and complete, and usually fragmenting landscape more and more. Wtf, people? Why, why my first mandrake install in 1999 was more coherent across *all* applications, while still being user friendly for a complete noob (after getting it installed), than default installs of most modern distros?
Yep if alright posted this in the Mint forums.
http://forums.linuxmint.com/viewtopic.php?f=61&t=120616
As just recently came back to give linux another whirl. And been seeing the same kind of things from 2008 when I left to now. Same just accelerated & magnified degrees of fragmentation.
With many main issues like video,sound,wifi. New Kernel breaking things that use to work.
And all the developers on the Bling bandwagon obliviously ignoring the cracks in the wheels & axles. And too many trying to steer the wagon makes getting there a less likely prospect.
“Compiz on maintenance-only mode, no port for Wayland”
This may not be precise. There may be other maintainers who would like to do the job.
Of course. There may be interest.
However it would be a difficult job, and for the reasons I’ve stated above, I would advise against it.
I would get behind an effort to bring the old functionality to newer codebases.
So you are waiting for new WMs targeting Wayland? Or to start a new project?
There is already a de-facto system compositor for Wayland. Weston.
Weston already supports lots of the useful things that were in compiz, such as display-level-zoom.
What I’d be saddened to see is wayland become the “waylands”, where everyone has their own implementation and we have to rely on standards processes and often ambiguous protocols for the sake of implementing something. I’d also be saddened to see a situation where we have one component of the stack becoming even more monolithic in its design, and this brings every other project that wants to have a WM to the point where multiple parts of that system which don’t need to be written multiple times get written multiple times.
Wasn’t KDE going to port it’s window manager (and compositor) anyway, creating fragmentation anyway? This due to not agreeing about Client Side Window decorations. Or are they going with weston and adding the functionality they want on top of it?
How hard will it be, in your opinion, to port the effect plugins…I mean, the logic for them is in the code, so how compatible are the surface contexts?….What really got me interested in Wayland in the first place was the idea of placing multiple vt’s on a cube, and having the WM -> Compositor -> kernel architecture right….
I suppose this is your personal conviction and Canonical will continue to use Compiz. Am I right?
(Compare it to upstart vs systemd, although it is not exactly the same in this concern)
I’m no longer employed by Canonical Ltd., so what I’m saying here doesn’t have any effect on what Canonical wishes to do. My understanding is that for the foreseeable future, the intention is to continue to use compiz as the window manager for the Unity shell. Something that in my opinion, makes a lot of sense. These days compiz is relatively stable and has lots of test coverage. It was a rough ride to get it to that point, but the whole system is workable now. I left for reasons completely external to what I’ve just said now, and those reasons were personal in nature, and not to do with the company. I would have continued working there had my personal circumstances not changed.
There’s not a whole lot of drive within the Unity community or internally in Canonical to “develop” compiz into something else. What I believe everyone has always wanted was a window manager that was fast and just worked. I think we’re 90% of the way there now, but in getting there, we obviously regressed quite a bit on these goals.
Window managers and compositing engines are suprisingly boring pieces of technology. Once you get to the point where the user can control the positions, sizes, focus and stack order of their windows on screen, and your compositing engine can draw them on the screen at a decently fast level, you’re basically feature complete, and the rest of the work involves bug-fixing and corner cases, and perhaps performance.
I always intended to continue doing compiz maintenance when I left. And I still am in fact. I think there are areas where we can make it go faster, some bugs left to fix. But after that there’s not really all that much more.
Another (more personal) question that comes up while reading your article is : Do you think the other codebases you are talking about are superior or do you stop development because of the will not to redo things? But even if it was the latter, it would mean compiz is behind other possibly codebases. I would be very glad if you could give an answer to this question.
I think every codebase has is strengths and weaknesses. I know the most about compiz, so I can try to objectively list our strengths and weaknesses:
Strengths:
1. Basically no dependencies except boost, cairo and X11. (This is also a weakness though because it led to a stupid amount of wheel re-inventing)
2. Compiz has solid test coverage, last check was 1200 unit tests on my experimental branch and about 1000 unit tests for lp:compiz . And they each test different codepaths.
3. Our plugin architecture is amazingly flexible. Unity can do basically whatever it wants, and its only a plugin for compiz.
Weaknesses:
1. Our window manager implementation is not all that great. For a long time, to be completely honest, I don’t even know why it worked. Just reading the code, it shouldn’t have worked. It suffered in numerous places from the disease that is treating X11 like a black-box, and placing protocol calls all over the place which “appeared” to fix bugs, but in fact masked them later. I can’t really objectively say this, but I think its in a much better shape these days. There are still some things in there that I know don’t work, but the whole thing is much more deterministic now than it was then.
2. Our compositing engine isn’t the fasted anymore. Phoronix and friends will tell you that. This is the number one point I’ve been trying to address lately. Its slow and it shouldn’t be.
3. Compiz was never embedded in an external community larger than itself like GNOME or KDE. This meant that as a project, it was automatically at a disadvantage past the “burnout” period for getting new maintainers, because it doesn’t have the same gravitational pull as the former.
One thing that I’ve realized about these strengths and weaknesses is that if you evaluate them, they exist at a project management level and not a codebase or fundamental technical level. They all existed because we had to re-implement the same thing as every other window manager, and copy-and-paste was not an option.
What I’m trying to say is that in the future – screw that. It completely sucks for everyone to have to do the same work N times and to have N differing implementations which are ever-so-subtly different, when really, that work could have just been done once.
Everyone’s implementation of window re-parenting is basically the same. There is no “better or worse” approach. You create a new window, change the client window parent, change the client window save set and start managing requests relative to the parent. There are a few comer cases to consider to, but they all need to be handled in exactly the same way.
Getting that stuff right is hard. We don’t need 12 different implementations of it.
Can you imagine if there were 12 different implementations of handling screen resolution changes inside of wayland compositors? Can you imagine 12 different implementations of GPU buffer management?
This mailing list thread about _NET_WM_STATE_FULLSCREEN_EXCLUSIVE here: https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html has gone on for about 60 messages for over three months. It has grown to be massive. Can you imagine 12 different implementations of that? Remember – they all have to do exactly the same thing otherwise it won’t work. There’s no way it should be like that. And I think if you asked every single WM developer, they would much prefer it if that work was magically done for them rather than them having to re-implement yet another spec in order to be compliant.
The way to fix that is simple. Have one window manager, which does all the boring stuff that everyone agrees on. Have a means to inject policy and functionality into that window manager so that people can customize it for different UI designs and off you go. Share as much as possible.
New projects which directly compete with others should only come about because of licensing concerns or ownership concerns. As a necessary evil. There’s not multiple implementations was of defining UI toolkit. Its a UI toolkit. As are window managers.
Thank you very much for your response! I appreciate that!
I really hope your wish becomes true for the Wayland times! But I am not sure if this is very likely, as Mark Shuttleworth stated to port Compiz to Wayland. Martin Gräßlin also plans to port kwin to Wayland. And there is also Mutter … So there at least 3 different projects …
I still hope your vision becomes true.
Mark never said that he wanted compiz to be ported to wayland. There’s a bunch of misinformation around that.
Have a look here: http://www.markshuttleworth.com/archives/551
“The next major transition for Unity will be to deliver it on Wayland, the OpenGL-based display management system.”
The goal is to deliver Unity on Wayland, specifically with the goal of getting away from X11. What Mark tends to mean by “Unity” is often quite an abstract concept and not a concrete reference to a particular codebase. Unity has taken three forms since its inception (Clutter/nux/QML), and may take others. Unity is architected to be mostly WM independent. It is implemented as a plugin for compiz, but you can actually run all of the different parts of it standalone in their own window.
Whether or not Canonical wants to take compiz over is another question. I don’t think they would. Compiz is a huge project, it just doesn’t make any buisness sense to put in all that effort.
Thank you for clarification!
So if I understood right (please correct me if I am wrong), you say Compiz is a good WM for X and should be ready now for good and stable performance. It does make sense to use and develop it for X, but it does not make sense to try to port Compiz to Wayland, as the codebase is to huge so this would be a too huge effort. Furthermore a port would cause many things to be redone, a thing we do not want to see for Wayland.
So let’s use the possibility to make things better!
Thank you Sam!
Not sure if you were being sarcastic or serious with your list of user-facing features. I have neither the cube nor fire plugins enabled, few animations (none lasting longer than 150ms) but do use scale (with the title filter plugin – about the only window picker that comes close to the usefulness of the venerable task list and a lot more keyboard-friendly). Compiz’s full-screen zoom implementation remains the only one I’ve ever used that hasn’t made me want to pull my hair out. Wall also provides a much more useful overview and management of workspaces than the cube ever did (although it used to – I’m still using 0.8.6 on my main desktop and I can drag windows between workspaces there; I recently tried stock Ubuntu 12.04 and whatever wall-like plugin they’re using lacks any such functionality, hopefully that’s not the official compiz plugin). I also enjoy the added functionality offered by Emerald (half the reason I’ve not upgraded).
There may be a lot of silly nonsense left over from Compiz’s proof-of-concept days but it is also the most downright useful WM I’ve encountered. Kwin is the only other WM I know of that comes close to matching Compiz’s functionality and utility but with a greater performance overhead and less tweakability (although I haven’t tested it for a couple of years, it may have improved in both regards), never mind myriad KDE dependencies.
I was serious when I posted that list, though its just anecdotal evidence. There are plenty of other use cases which are totally valid too. Lets take those usecases and put them all in one place.
I’m so happy to read this post from you, Sam.
This year more than ever I have felt growing frustration with the situation involving the competing window managers in Linux systems. This is a level of the stack that is so complex, with so many different configurations and corner cases, that it is clearly a prime candidate for collaboration. Differentiation happens above this layer.
Instead each camp has worked on its own implementation, duplicating effort and missing perfection by a wide mark.
What exactly is the benefit of open source if each organisation works on their own independent code base, and therefore improvements are not shared? How is this any different to a proprietary system? Except that the makers of a proprietary project would realise how foolish it is to try to maintain something like this on their own unless backed by considerable resources.
My hope for 2013 is that those involved can display some of the awareness that you’ve shown here, put aside their differences and petty politics and work together to produce the great software we all know is possible. Also world peace, and perhaps that is more likely?
Thank you, and happy holidays.
If you drop compiz development you do not make things better, after all the hard work and improvements. It is not sensible to drop a project that gets that much attention and is supported by a powerful company.
You want to drop compiz development in order to reimplement things unique to compiz on a newer codebase? I cannot see how you want to prevent things from being redone this way.
In theory your approach of shared code bases may be ideal, but that is not how the world works, not even for opensource projects. Someone could say: Why has every country his own government, that reinvents laws, why not having a common government for the whole world? You can see, this does not make sense. It would make sense, that the governments communicate better with each other, but one common thing or base is not always good, this is not the human nature.
If you ask me, you make a big mistake by dropping compiz. The project would loose an excellent developer.
Think about that.
“In theory your approach of shared code bases may be ideal, but that is not how the world works, not even for opensource projects.”
I disagree, there are various examples of open source projects where most of the community congregates around a single code base.
Most obvious is the Linux kernel. CUPS, maybe. X itself could be an example, since the original forking from Xfree86 over a license disagreement led to all development moving to X.org within a relatively short time frame.
These are all projects which have to work across a large number of different hardware, software and driver configurations. Stamping out all the little bugs that crop up in specific circumstances it what takes up most of the time. They are also all parts of the stack that make no sense to compete over.
Of course there are still “competing” alternatives even in these cases, but in a good situation the alternatives only gain traction if they have a real technical reason to exist, rather than some accident of history (and the resultant politics and ego).
It’s unavoidable to have competing visions for the desktop environment, for example. But there is good reason to collaborate on the window manager, otherwise each project has its own unique selection of bugs and quirks and none of the fixes can be shared. Which is what we have at the moment.
This is supposed to be the point of open source development, producing more stable code and doing it efficiently. Otherwise really, what’s the point?
I’m not going anywhere 🙂
As I stated, I’m still as committed as ever to maintaining compiz in its current form.
I’m not as committed to the idea that we need to maintain it along side every other window manager forever. Or at least, I’m not committed to the idea of “compiz as a project” anymore. I don’t think that makes any sense.
What I’m totally committed to is what it brought to its users. There isn’t really a community around this project anymore. There’s no users buying our “why”, but only users using out “what”. That’s great, actually. It means that we know how we can best serve user interests from this point forward, because we know about what they actually care about.
My post here is a challenge. Instead of constantly competing against each other, why not figure out where we can work together on implementations. I think all of us will be much happier once we start doing that.
If you want to work on a common implementation of something in a Wayland world, do something about client-side decorations. If nothing changed in recent weeks, Wayland demands that each application implements its own window title bars which is absolutely retarded because it means that we’ll transition from a handful of competing title bar implementations (one per WM) to countless implementations (one per application).
A common implementation (libwindeco, some dbus-based thingie, or whatever) which allows the DE to set a session-wide Look&Feel would be great, so that under Unity close buttons are left and the title bar is hidden maximized, under GNOME Shell no minimize button is there, etc.
For me, I was using compiz because of the wobbly windows, low amount of dependencies for its features, and the vast amount of configuration that it provides. I’m still on the legacy branch of compiz because no replacement for emerald exists that’s up to whether emerald is. Normally I would try to attempt to make something similar for the new decoration API, but it keeps changing from the last time I got it working with the most recent Compiz.
What will happen to my wobbly windows! 😦
Ideally, they’ll be implemented for weston.
The codebase is free software, so its not like you’re compiz or bust.
Three questions –
Do you intend to poke around the weston code base, and perhaps lend your experience there?
Given your apparent stance that as much duplication of effort as possible should be avoided, what is current current stance on the directions that the other major DEs’ WMs are headed?
Similar to this, what do you think of the current clutter of tiling/dynamic WMs out there (i3, dwm, awesome, xmonad, herbsluftwm, wmii, to name but a few…)? Do you think there is a lot of duplication here (it seems to me there is), or the separate efforts are warranted?
Lastly, thanks for being a valuable contributing member of the linux community as a whole!
Maybe I will poke around Weston. I have some other things that I want to move on to though, which I think will probably be much more boring, but probably be quite useful for everyone in the OpenGL community.
To the other compositor and window manager authors:
Get together and collaborate to form a common codebase for what you can. There are so many boring details of weston compositors that nobody cares about, but everybody has to do the same in order to ensure interoperability. If you have to have a specification on “how clients communicate with a window manager”, and then go and implement that spec for every single compositor, you are doing it wrong. Nobody wants to sit at their desk for hours on end debugging some crazy application behaviour with their reparenting code for the sake of standards compliance when there is already a working implementation out there.
Writing an OpenGL engine from scratch is really really hard. You have to think about the right abstractions, performance, incremental updates, geometry clipping. There’s not “two different designs” of these things – there is the good way, and then there is the better way.
If you just maintain a normal noncomposited window manager for X11, then I can guarantee that you won’t be interested in re-implementing all the little details of the compositor. Weston’s gl compositor module is a good start for this kind of thing.
The idea of standardization is awesome.
How will you begin collaboration efforts? If nobody organizes the developers, your ideal scenario will most definitely never happen. Somebody needs to organize them (friends at canonical?) and ask for cooperation. If nobody owns and executes this step it will never happen.
Hey there Sam, just thought you might want non-anecdotal reasons this user runs Compiz:
1. I can have tiling effects in Gnome 2 without resorting to Awesome, Xmonad and others that require a degree in quantum mechanics.
2. I can feel good that I am making use of my 3D card and hardware to make the desktop more attractive.
3. I want better window management than what Gnome 2 gives me by default.
And just in case, here’s the CCSM profile I’ve been using the the last 6 months or so:
https://dl.dropbox.com/u/7890536/imran-uk-compiz.profile
post-desktop? post-X11??
Quit drinking the pointy-haired boss bullshit-aid. Tablets are not computers and because of that cannot ever replace them. And Wayland is an utter piece of shit from idiots who think iOS/Win8 is actually the way to go. A mindset of mind-boggling stupidity, by stupid people, for even stupider people.
If you want to help build the Idiocracy, go do it on another planet, and everyone who does shall take their FAIL with them.
I bought an Transformer Prime a year ago for uni and I still prefer using my laptop, and obviously don’t use weston at the moment. That doesn’t mean its not where the majority of users will be in a few years time.
Reblogged this on txwikinger's blog.
This webpage says canonical will port compiz to wayland.
https://wiki.ubuntu.com/Wayland
“The way to fix that is simple. Have one window manager, which does all the boring stuff that everyone agrees on. Have a means to inject policy and functionality into that window manager so that people can customize it for different UI designs and off you go. Share as much as possible.”
and
“Unity is architected to be mostly WM independent. It is implemented as a plugin for compiz, but you can actually run all of the different parts of it standalone in their own window.”
So, do you beleive there can be a consensus to build Shells on top of Weston?
Are KDE, Gnome and Unity going to build on top of Weston?
Can they be interested in start building on top of Weston?
I think with your views as expressed above and your experience as stated above,
you are in a unique position and possibly the only person who can make this happen.
Someone who can make the big projects realize that by gathering around Weston
they would gain, rather than loose, creative possibilities.
Instead of doing duplicate work and hunting duplicate bugs, they could do it once
and then go on making their version of the user experience as good as possible.
So please be a leader in this.
Many people that diet solution may have led to initial buy raspberry ketones but
then the results will not be maintained. Too many
poor quality calories, insufficientExcess weight in children is linked
to many of the reviewed studies were of poor
quality.
Wayland is a step forward. But what is really going on here ? Look at WebGL. The context of the “desktop” gui is changing radically along with social changes related to the internet … See … https://despora.de/posts/1502548
About “fragmentation”: One size does NOT fit all, you idiot! The fact that they all imitate each others’ shittiness is NOT an argument for just having one. It is EXACTLY what having different projects is supposed to CURE. It’s just that nobody expected the developers to be SUCH massively insecure passive-thinking cattle that they *still* do nearly exactly the same!
That does NOT mean having separate projects is “bad”. It means that the developers are a bunch of massive retards that should but a spine, some balls, a upgrade for independent thinking, and an actual vision!
> an effort to bring the functionality that people loved
Yeah, where is that actually?
You killed Compiz, and even years later there’s nothing even remotely offering the same plugin set and configurability! KWin is a freaking joke of vomit and crappyness. (Just look as that damn “cube”! LOOK AT IT!) And Gnome and Ubuntu is an apocalyptic hellscape of a nightmare of utter iTardedness. Pussies who shit their panties over “Ohhh, our *tiny* brains can’t handle all these features! Waaahhh! Better *delete fucking everything*!!”
And I don’t give a fuck about stupid gimmicks like painting fire or having fish tanks.
I care about being able to freaking Win+Mouse3 on a window, to close it!
I care about configurable shortcuts! And proper shell-scriptability! (No KWin, your over-engineered shit that requires one to learn to program Qt/KDE doesn’t qualify.)
And I care about *beauty*! (Dragging windows by Win-Mouse1-ing *anywhere* on the window, with a slight wobble to show when it snaps to something, again, is a ridiculous joke in KWin.)
Oh, and while X11 is definitely old and requires a rewrite, Wayland is the biggest turd the iTard Linux metastasis ever pushed out of their mental anus!
It goes against everything that is Unix and Linux, because the morons who made it are too fuckin’ stupid to even *know* the damn Unix philosophy and why it evolved and was established over decades!
Call me when the compositing, window management and the GUI is accessible via the file system!
The way I see it, you massively failed. That is not the problem though.
The problem is that you don’t think *you* failed, and that you think you’re on the “right” track now.
I HAD TO GO BACK TO KWin! That’s like going back to Windows from Linux!
(No, Ubuntu stopped being Linux. I mean actual Linux for actual computer users! Not drooling iTards!)
I have still not forgiven you for that!
One thing good about the whole corporate world, is they get things done ORDERLY. Market is always considered the best method of resource allocation, but it’s sadly no market in FOSS. It not a market because people do not pay prices. They actually do, only economically, pay opportunity cost, but it, as always in accounting sense, is ignored. As much as I love open source, it is always behind in terms of entertainment (which drives the consumer computation technology) and system integration. It cannot be the pioneer. It is only a free repository, free in free of charge, not the Utopia for Mr. Stallman.
Gone are the good old days when people realize cooperation is better than competition. Someone mentioned Unix philosophy without stating it. I wonder, if Unix philosophy is forking and departing, then wouldn’t the philosophy itself be forked and departed? As far as I know, UNIX meant “do one thing and do it extremely well”. Not something can be achieved by forking, I can tell.
Considering “The Editor War”, I am glad only two, each representing its own philosophy, editors are involved, instead of loads of bloated variants. Yet, emacs is naturally varying, and vim is being refactored for better integration with other tools. At least they are not rewritten from scratch, as Sublime and Atom.
Wish you all the best luck on Wayland and Weston. Pardon me as I am going back to the origin of computer market and enjoying my Apple products.