Plasma Active is an extremely awesome project and I am really looking forward to work on it and have my first own Plasma powered tablet. Of course KWin will be the Compositor and Window Manager in Plasma Active. And this is pretty awesome and very interesting for our future development.
KWin on OpenGL ES 2.0
Plasma Active will probably be the first large installation to make use of our new OpenGL ES 2.0 based compositing backend. In fact OpenGL ES is our primary target because the API is way more advanced than desktop GL and gives better results. Unfortunately the decision whether to use desktop GL or OpenGL ES is a compile time decision. As not all drivers support OpenGL ES on the desktop we still need to default to desktop GL. On Plasma Active we know the driver to be used and therefore can compile against OpenGL ES if supported.
OpenGL ES is far less complex than desktop GL. The desktop stack still carries around the complete outdated and deprecated OpenGL 1.x functionality. It is not surprising that writing a desktop GL driver is difficult. Because of that I expect that the hardware running KWin in Plasma Active will be faster, more energy efficient and magnitudes more stable. It will be the first important step to leave the messy state of OpenGL on Linux behind us.
Different Focus
While Plasma Active still requires a window manager, the superb functionality known from our desktop and netbook shells are not required. By targeting touch screens without keyboards quite some changes to our way of thinking how to manage windows are required. My personal pet Alt+Tab is completely useless on such a device. In order to make it usable we will need to adjust and drop the requirement of holding the "Alt" key. This will of course benefit the desktop users: switching windows could become possible with multi-touch gestures on a touchpad.
Another area of change will occur for window decorations. In fact in Plasma Active there won’t be window decorations – they are just not needed. No, I don’t twist my mind, we won’t introduce client side decorations. We just won’t have decorations. The only relevant button (close) is put into the panel. Also that will need some small tweaking of the KWin source code like many other little advantages we have to make which all will also benefit the desktop.
KWin and the Device Spectrum
Plasma supports the complete Device Spectrum by using custom shells and different QML files for the widgets. Now KWin does not (yet) support the various form factors in such a way. From the window management perspective there is nothing to change. Since the introduction of the netbook shell we know that adjusting KWin just means to change the configuration. KWin already includes all the little tweaks required to have a pleasant experience on systems different to the desktop.
Also in the compositor there is hardly anything to do. We support OpenGL ES and the general compositing doesn’t change just because we run on a gadget. There might be some adjustments required for the drivers as we did not yet have the chance to play with many of them but in general I expect everything to "just work".
The only field which requires adjustments are the effects. Many effects are just not suited for such devices and we will not ship them. In fact I expect that we won’t even allow to customize the window manager and effect system. The danger to harm the system are too high. And some of our effects need adjustments for the use on such a device. Let’s take the Present Windows effect as an example. It allows to close a window when hovering over it. Closing windows from the overview is damn useful (I got the inspiration from Maemo), but hovering is just not possible on a touch device.
In order to properly support both Present Windows on the desktop as well as Present Windows in Plasma Active we need two distinct Present Windows effects. Now writing something like Present Windows is far from trivial. The effect is complex and around 2000 lines of code. We need a better solution for that.
Over the last weeks and months even before I knew about Plasma Active I started to think about how I want to have effects being developed. My aim is that Nuno is not only able to write effects, but that he wants to write the effects. My task is to give him the tools to do so. Over Tokamak next week I will sit down with our QML and JavaScript binding experts to discuss and implement a solution for KWin. A subset of the kwineffects API will be stabilized and be made available for bindings. After lots of thinking I am sure to have found a solution which allows us to write effects in JavaScript and/or QML without spending time in the interpreted part during screen rendering. This will allow us to write effects in a more suited language with the speed of compiled C++ code. The first effect I want to port to the new system will be the Present Windows effect.
In that regard I want to have Plasmate also as a development tool for KWin effects. This will take some time, but I have ideas how we can get previews for the animations and effects outside of KWin. I am both looking forward to implement these parts as well seeing them used.
New Technology for the Desktop
Some of my last blog posts were rather controversial and that was not by chance. I wanted to test out how users will accept the changes which are implied by Wayland. I wanted to see how much acceptance there is for removing features on the Desktop in order to go to a new windowing system. I am very thankful for all the comments I received and that there was some media coverage about these posts. It was very enlightening to read all those articles and comments to them.
My fear that it is not yet acceptable to aim for Wayland was overall confirmed. Especially for KDE it seems that our users do not want us to remove any features. Everything has to be configurable, we "may not go down the GNOME road". For the adoption of Wayland we have a chicken and egg problem: as long as it is not used, applications won’t be ported, as long as applications are not ported it won’t be used. This is similar to what KDE faced in late 2007.
Now Plasma Active gives us new possibilities. Having compositing always enabled is not just a nice thing, it is a requirement which we can fulfill thanks to the advanced drivers compared to the broken state on desktop. We can experiment with moving the screensaver into the compositor without ensuring backwards compatibility. We even do not need to support widgets in screen locker on Plasma Active. This gives us the advantage of first implementing the new functionality and later add the backward compatibility layer for the desktop systems.
And now: Wayland. Wayland is a very interesting technology but it will be difficult to embrace. There is so much depending on X that we have to either port everything and then do the big switch or dare to break functionality. Both is hardly possible on the desktop. Announcements like Mark Shuttleworth’s "Ubuntu 11.10 might use Wayland" do not cause joy in me but fear that it will harm the platform like the too early switch to PulseAudio. Wayland is too important to risk that users think it’s bad because someone just wants to be quick.
Plasma Active on the other hand is a wonderful candidate to embrace Wayland. The stack would significantly benefit from dropping X11 and using Wayland as the windowing system. The driver situation is good: the devices run OpenGL ES 2.0 which is a requirement for Wayland. But most important: we don’t need the window manager. We only need the compositor and effect system – both is basically independent of the X11 stack and can rather easily be made Wayland ready. On Plasma Active we don’t have window decorations, so we don’t need to port them and so on and so on. This gives us a third possible strategy for approaching Wayland: port step by step and use it and do not switch on the desktop before everything is put together. Please don’t over estimate this statement: it is a long road to Wayland and the first release of Plasma Active will not use Wayland. There is lots of work to be done in KWin before we will consider to add support for Wayland. This will most likely not happen in 2011.
How to get involved
KWin can use helping hands. We are only three developers and none of us can work fulltime on KWin. There is enough work to be done for fulltime developers, so we need new blood. Especially after the first support for JavaScript and/or QML is added we need help to get effects written in that language and Plasmate adjusted. These are things I would not want to do. So please get in touch with us either through the mailing list or in one of our IRC channels: #kwin, #plasma or #active are all fine. Please don’t overrun us, we are a small group 😉
=-=-=-=-=
Powered by Blogilo
Very insightful blog post (again), Martin. 🙂
Also, the strategic bits seem sensible and well thought through.
I think this is definitely a great development. The future of computing will certainly be influenced by the advent of affordable and flexible tablets/touch devices. We are witnessing an explosion in this sector, and just ignoring this trend and wishing it was only a fad would be quite stupid.
Furthermore, now we have tablets like the Transformer by Asus, which seems to be the ideal development platform; it has USB ports, a keyboard to type some code with, a nice amount of processing power, and a decent price. Another sign that the market is maturing enough.
The time is ready to make the kind of courageous decisions you are talking about: this is an opportunity for many projects to have a fresh start, and step out of the comfort zone and explore new approaches to a new reality.
It seems that you failed to notice that you should focus in fixing KWin for the desktops, before creating ANOTHER useless project. Let’s summarize this:
Why don’t you insert your plasma-enabled tables in the anus?
Greetings.
Do you think you can change my mind by being insulting?
Well, KDE 4 has been out for a looong time and you didn’t listen to the users, KWin was, is and will be crappy (compared to other compositers), so I consider insulting as the only thing left.
And don’t try to defend yourself saying “it works in my machine” because that’s not an explanation. For example, the previous post of this blog explains that a bug remained undetected just because you didn’t give it attention.
And I say “attention” because I’ve seen LOTS of people joining #kwin and then saying “hey, blur doesn’t work in my card” and then you’d reply “it’s intel’s fault”. And now, after several months, you realize that it was your fault.
Incompetence or malice.
You know more than I know. I cannot remember people just telling it’s Intel’s bug and the fix for the desktop is in mobile with GLES. And no insulting is no solution, that just gets you on my ignore list. Good luck with that attitude.
Again with mobiles and tablets.
Dude you perfectly know that developing KDE for mobile phones and tablets is like… a game. Everyone knows that that has no future AT ALL. Noone will run KDE in his mobile phone. STOP. And this is not only for you but for Plasma developers as well.
So, please, enough with that. Consider we’ve ended with that useless arguing about KDE mobile.
Fix KWin. We’ll be happier. You will get less bug reports, and the users will get a better product.
If you want to tell me what I have to work on, please start paying me. Up to the date I do that as a volunteer I do what I consider the most useful path.
If I pay you, you do your job? Seriously, we could make a deal.
I wouldn’t pay everything, but we could make a Flattr account for this, “Help fix KWin”, I’m sure it would be successful.
That’s actually an idea. Martin up for it? If it works you would make money out of an activity you enjoy: making kwin better.
I’m not rich but I could give something. Many other people would support you too I guess. It’s a Win-win.
No, because I don’t like the idea of flattr at all.
I don’t like when I have to say things like this one, but… you don’t even know what you want. I’ll tell you what you should do: fix KWin. Get testers. You have a lot of them at #kwin. Make us happy. Forget about mobile phones.
Please.
what do I want with a few cents through flattr? Seriously if I get paid I need to be able to live from it. If not I am not willing to be command around because someone gave me a dollar.
Hire a programmer or shut up
Why doesn’t my last reply appear in a thread under shlaunchpropsheet’s comment?
WordPress – only supports threading to three levels 🙁
Well, Martin is not perfect, the code there is a bit crappy, yes.
But hey, you know what? It is OSS, if you don’t like it – change it.
I am sure that martin will happily accept any working patches for 4.7, and I’m quite sure a lot of distributions will backport it.
Insulting is just stupid. Seriously it’s very counterproductive as what you can achieve with it is developers becoming defensive and even more entrenched in their beliefs. It’s not a rational way of doing anything.
You may be right that KWin really needs more development (e.g. support transparent styles! one of my pet bugs, though there are a million more serious problems with kwin), but you don’t attract more developers by making their jobs unpleasant with your attacks.
If you can code you can contribute to the project yourself, if you can’t you can go and persuade more developers to join the team. If you’re not really bothered then you’re just trolling here.
What you failed to notice is that Martin does this in his free time, and can work and do whatever challanges him, and is fun to him. It is simply not of any interest what you think, or I think what Martin should work on because it fits your or my personal needs better.
I personally see tablets as the most pointless device made in the past century, because I do not have any use for it. This stands for my opinion, and does not imply others, who may have a use for it, and I could think of opportunities (in example Hospitals, who could greatly get rid of a lot of paperwork by carrying a tablet with the according software files around), and others who also may see a personal use for tablets.
If you don’t understand how free software works, how contributing to the community works, well… Go back to your windows installation.
Great stuff Martin, a lot to be excited about with the Plasma Active initiative and the direction it brings kwin. Please ignore the naysayers, you guys do great work and its unfortunate that driver issues are blamed on you.
Just wanted to ask whether javascript driven effects will be downloadable via GetHotNewStuff? It would be an incredibly awesome way of involving the community and trying out interesting things. No doubt that all the spinning cubes compiz brought to youtube back in 2006 tremendously helped in bringing new users to the desktop.
Interaction between kwin and plasmoids that are user configurable through javascript would be incredible; imagine a clever rss reader that floats elegantly stylized updates across the screen, or does so below the top most window…
Will eventual Wayland integration likely significantly improve responsiveness? E.g. X seems to freeze up when one application is scrolling amongst lots of other little micro issues that seem to hurt responsiveness with many windows open.
Just ignore them Mr. Martin!
Ignore all these people who want foss to stay only in servers and geek-pc’s.
ps, I love kwin
“Unfortunately the decision whether to use desktop GL or OpenGL ES is a compile time decision.”
Really? Surely even if the worst comes to the worst you can dlopen one of two different libraries at runtime after testing for GLES.
(I’m sure kde has some sort of framework for doing it more elegantly though)
Martin, you know that many developers nowadays live by such means. Developers much less skilled than you working on lesser projects. Even some developers of firefox addons (such as adBlock Plus, which is the best addon, actually) do that as a full time job. And they are developing a humble firefox addon! You are developing KDE’s default window manager and compositor, for crying out loud! Do you realize how important your work is to how many people? It’s not an exaggeration that every KDE user in the world directly benefits from your work. You will get support. Do a poll, ask if people would support kwin.
Look Compiz is backed by novell, canonical and other major names. Wouldn’t KWin like some backing too?
Then it’s not a question to be ordered around but to just run a business keeping your “customers” in mind. I would give it a try if I were you. If it doesn’t work you won’t lose anything, you can just go back to how you develop now. If it works you have a nicely paid part-time job, or even full time if it goes really well.
Who knows maybe people will see that there’s money to be made like this and more and more will develop for KDE. Why do you think that firefox and chrome have so many free addons (with donate button)?
But yeah it’s your choice, surely none of my business. Just thought this was a good idea worth trying that would benefit you as a developer, and us as KDE enthusiasts.
Anyway I sincerely like your idea of expanding kwin to other platforms. We just need to get more developers involved. If people saw there was at least one guy who made at least some €uro$, it wouldn’t hurt would it?
Best wishes
I’m sure KWin would like some backing but you overestimate the support for Compiz. At least Novell doesn’t emply anyone working on it, maybe since a few months Canonical has someone part time (but Canonical isn’t known for their upstream contributions so it’s not even sure code actually makes it back to compiz).
If you know a way to get money to KWin, sure, take care of it. I’m sure other projects in KDE would be interested too. Firefox addons are only written by full-time developers if they make money on it, you know…
A customer is someone who pays – do YOU pay for KWin? Aaah, you don’t. You know anyone who does? anyone who would? No? Neither do I. So this won’t happen unless somewhere someone is willing to pay. Don’t count on Novell, Red Hat or Canonical, btw. They won’t.
Dear Martin,
please let me state the so obvious. It is extremely impressive what you do for KDE, what you know about the subject, and how friendly you stay despite this negativity from some “users”. Please continue your great work!
Markus
Martin,
I thought I’d express my deep gratitude for your team’s work here as a very satisfied user; KWin seems to be on a very solid path.
I should remind you that the criticism Pulseaudio got was nothing compared to what ALSA got when it was first introduced. The “I want it to just work” crowd is typically louder than the “What is this thing trying to accomplish and how can I help?” group.
As for Wayland, if it’s the only way to get working video VSync under compositing and seamless Fast User Switching, then so be it. You don’t owe anything to the “entitled” people anyway.
Lastly, if dlopen won’t work, how about producing two executables (and maybe a wrapper as well), one for OpenGL and another for OpenGL ES?
Thank you again,
a deeply satisfied user.
it’s currently mostly lack of time that we do not yet have two executables, but it is one of the ideas I had how to get it working.
these comments make it seem like martin is the only kwin-dev… although i don’t know if that’s true i heavily doubt it.
if you want your bugs get fixed – fix them or try to attract more developers who might fix them for you 🙂
actually, that’s why i think the mobile direction is a good thing. even if it would turn out completely useless – it still creates momentum – i.e. attracts new developers.
and just to add one more blabla -sentence: if we’d always waited for all bugs to be fixed before starting sth new, we would still use ms-dos or whatever we started with…
It’s amazing how stuff like blur that wasn’t even there in 4.4, caused difficulties for some driver combinations in 4.5, and is virtually perfect in 4.6 is suddenly so mandatory to the user experience that all of KWin is ‘completely broken’ if it switches some demanding effects off when necessary.
My opensuse laptop 11.4 with a 2008 INTEL 965GM GPU is working flawlessly. Fast, CPU usage~2%, no serious crash since its installation. The first thing I notice with every new version of KDE since 4.2 is how much faster plasma+kwin have become. My current whinelist/wishlist is actually pretty close to what Martin is blogging about: Activity aware grouping, tabbing, and the option to put the menu in the decoration or toolbar. All luxury and optional.
KDE has this perfect opportunity to give me a unified UX on my workstation, laptop, tablet and phone – now that is an unique selling point; go for it.
While I’m perfectly happy to pay hero’s like Martin for the OS that they’re building me, I don’t believe that we’d make the 20k euro to do so. If anything, It’s up to the distros I guess.
I do not share the tone of shlaunchpropsheet but there is a basis of truth.
Lately KDE is focusing on mobile devices and tablet but is losing the Desktop.
Before starting new adventures (in other world) I believe it is essential to a great effort to correct the base (bug fixes, stability, driver, fix UI).
Many people approach to KDE because it is beautiful but at the same time leave for the reasons I said before.
Just because not much money KDE should focus to fix what is already there before venturing into a new world.
With *sincere* respects,
just my two cents.
Thanks for you (and all KDE) great work.
A little bit curious and confused, what’s the relationship between plasma-mobile and plasma-active? One for mobile and one for tablet?
Hi Martin,
Thank you for the post, plasma active sounds like exciting stuff, and i am hoping its potential might be seen on whatever successor to the n900 Nokia releases.
I have a question which may be stupid as I am not a software developer:
OpenGL 4.1 now includes the functionality of OpenGL 2.0 ES and I believe that the former is a more or less a superset of the latter.
Does this mean that in future you will be able to enable compositing of Kwin via OpenGL 2.0 ES on the desktop for users with ATI/Nvidia GPU’s and proprietary drivers that support OpenGL 4.1?
And if this was possible, would this represent a ‘win’ for you given the relative simplistic and stability of the Kwin OpenGL 2.0 ES compositing stack?
Many thanks
JBT
KWin’s OpenGL ES backend uses 100 % the same OpenGL calls as the OpenGL 2.0 backend. It is the same code. The only difference is that the one uses EGL and the other GLX. That is pretty much independent from the OpenGL version.
thank you Martin.