KWin, KDE's window manager, has been around since KDE 2.0 (replacing KWM in KDE 1.x) and has grown to be a mature and stable window manager over the years. For KDE 4, however, there were a few people rumbling about visual effects, and perhaps KWin was feeling a little envious of its younger cousins Compiz and Beryl. While these new effects have created a lot of buzz around Linux and UNIX, long-term KDE users have wished they can enjoy the effects of Compiz/Beryl while still having the tried and tested window manager that is KWin. As a result, for KDE 4, KWin has received a huge graphical upgrade, with composite and GL support. Read on for more details.
KWin has implemented effects in a way that allows a number of different rendering methods to be used, depending on your specific combination of hardware and drivers. These features have brought KWin rapidly into the era of dazzling eyecandy, along with some pleasant surprises on the usability front. This effort has been spearheaded by Lubos Lunak (a man known for his efficient code) and his team, with special mention to Rivo Laks and Philip Falkner for their contributions.
Effects are disabled by default at the moment, although that may change before KDE 4 ships, and distributions may decide to alter this setting anyway. When enabled, the effects are designed to degrade gracefully. If GL is not available, KWin disables GL effects but still allows Composite effects where possible via XRender. If XRender is not available, it falls back to plain X, running in the same fashion as the present KDE 3 version. To get the full array of effects, you need to have a video card (and driver) that supports AIGLX, XGL or use the proprietary Nvidia driver.
Once the effects are enabled, it's simply a matter of choosing which effects you'd like to activate. So far, Rivo Laks has been working on the effects plugin selection interface (see the screenshot below). The new plugin selection widget shown is making its way into various parts of KDE - it does automatic dependency checking, so once the dependency tree is known, it will intelligently enable or disable dependent plugins. This widget is also showing up in other parts of KDE 4.
(as you can see in the image, this dialog is quite new - less than a week old - and is missing all the icons...)
Lubos has been periodically blogging about the effects that KWin is now capable of, and has recorded a number of videos showing them off. Since video capture on my system is rather chunky, I will present his recordings instead. So, without further ado, I present some of the more popular of his flash videos, hosted by YouTube. If you are interested in more, please visit his YouTube User Page
The Present Windows Effect - a very useful effect that falls into both eye-candy and usability categories...
The Desktop Grid Effect - those familar with the Cube effect may note that this is not quite as flashy, but probably more useful. Doesn't mean there cannot be a Cube effect for KWin though.
This one shows the above two effects, as well as the Alt-Tab thumbnails, but it shows that the effects work great, even when the windows contain active videos.
Zoom Effect and Magnifier Effect: some accessibility related features that everyone may find useful, depending on your specific needs.
Effects like this one make people go "Wow". The first part of this video features the Fall Apart Effect, which basically has a window blow up. It's amazing how well this effect can be demonstrated in a low quality flash video...
Aside from Lubos, many of the new effects and underlying core components were programmed by Rivo Laks and Philip Falkner. They are responsible for many of the effects you see in the videos, including the Present Windows Effect, and the improved Alt-Tab dialog. There have been a number of contributions from others as well, and they are always looking for new and interesting ideas. In addition, KWin for KDE 4 builds on the already existing KWin version which has had dozens of people contribute to it over the years.
The window decoration shown above is called 'kwin3_crystal' and is still set as the default in SVN. It is simply a port of the existing KDE 3 Crystal window decorations, however, a new KWin window decoration is still in the works for KDE 4 - it hasn't been made the default yet, so I haven't been featuring it. When it does eventually become the default, you'll be sure to hear about it here (and likely in Danny's KDE Commit-Digest as well...).
KWin for KDE 3.x implemented a very simple composite manager, allowing simple effects such as window transparencies, fading menus, shadows, and so forth. The code was not too complex, but the infrastructure was not in place to seriously extend the effects to GL powered goodness. When the KDE 4 development series opened, it was seen as an excellent time to rewrite some of KWin's internal structures in order to support such effects. There were initial considerations of implementing support for the existing Compiz and/or Beryl system of effects via plugins, but there were technological hurdles that prevented this. I won't go into the technical details as to why this decision was made, however, it is important to note that KDE 4 will still work with Compiz/Beryl should the users choose to use that software instead of KWin.
Additionally, while KDE 4 will be supporting a number of platforms with libraries and applications, KWin is one of the applications that will not be making the switch as it is inextricably tied to X. This should be considered to be a Good Thing(tm), as it ensures that KDE will always be the best looking when used with Linux/UNIX, and hopefully it (and related KDE Workspace technologies, like Plasma) will remain a unique benefit of using a more open operating system.
KWin promises to ensure that KDE get the graphical boost it needs to keep the eye-candy folks happy, while providing new and usable features for the desktop environment that would not have otherwise been possible. Yet, it maintains the rock-solid foundation that a long history as an integral part of KDE has provided. It will still work (with reduced levels of effects) on any system that KDE 3 ran on, so no-one is left out in the cold. It is already the default for KDE 4 in SVN, and will be showing up in future beta releases.
On a personal note, I've found that KWin on my system was dropping down into XRender mode due to some X settings I need to fix, but it has been perfectly stable for me over the last two weeks. In fact, every week when I'm rebuilding KDE 4 to write these articles, I am more amazed at how quickly it is becoming stable and useful. If you are interested in testing it out for yourself, check to see if your distribution has packages available. I am aware of the existence of at least one live CD (where you don't have to risk messing with your system) that is available at the KDE Four Live website. They update the Live CD every few weeks, and currently has the KDE 4.0 Alpha 1 packages. Additionally, if you are brave enough to test the Composite features, and are having problems, have a quick look at the Composite HowTo.. If you have problems, please report bugs using the the KDE Bug Tracker by selecting the KWin program, and the "composite" component.
Until next time.
Comments
"'perfectly valid reasons' were things like"
someone else filled in the details for you, if you look above there is a list of things kwin does right today that beryl/compiz doesn't. i try not to spend more than a minute or two writing replies here, so apologies for not being more thorough.
"I REALLY doubt it would be anywhere near as hard as duplicating that much of Beryl's functionality was"
well, it is. in part because the proper window management takes a -lot- of testing under all kinds of conditions and compositing tech is far more self-contained of a problem space: it either works or it doesn't. neither is trivial, but one is faster to get through. the work compiz/beryl have done also shows the way quite nicely; they deserve massive kudos for that.
we have a known good solution that our userbase absolutely relies on. beryl/compiz doesn't work for the entirety, majority even, of that user base. ergo the chosen solution.
btw, this isn't a kde thing. metacity is doing the same thing and, as i understand it, for the same reasons.
Yea! There's only one window manager needed! Oh - even more! There's only one desktop environment needed! And - uh! Oh! We only need one operating system! So why don't we all use Windows?
Why do people waste resources by making OSX, BSD, Linux, Symbian, ...?
Maybe competition and choice is a good thing? Maybe without competition there wouldn't be evolution (see Windows Vista as an example).
> We only need one operating system! So why don't we all use Windows?
The "don't duplicate efforts" principle is only valid in the Free Software world. Does that answer your question?
The only answer to this kind of absurd post is: go, buy a Mac and use the one and only OSX+Apple HW. You won't bother (or brotherr? ROTFL) anymore about fragmentation.
And anyway, if you really wnat to blame someone for creating "fragmentation", blame the author of compiz who started a new WM and not implemented it in KWin or Metacity (since it was a Novell employee).
Well thank you for the education on these issues. I do not know where I stand now. I do not think my concerns for what is best for the desktop are lessened but you all do make great points.
The simple point is: Compiz was a research project. It is now indeed duplicating stuff found in current windowmanagers, but that's THEIR waste of time.
The lack of a plugin infrastructure in compiz makes it impossible to directly re-use their plugins (though we can and do port code and ideas from them). And windowmanagment is much larger than compositing, so it makes more sense to add compositing to a windowmanager than a windowmanager to a compositor.
These words should be carved in stone... or at least used as disclaimer in every "KWin bling" post ;)
Vi forever!!!!1111
What do you suggest? That people shouldn't work on what they prefer to work on in their freetime?
Choice is one of the great things in regards to open source.
While I like these video's, there is one thing that Kwin still cannot do: really maximize a window! By this, I mean that the border around the window really disappears, and I can, finally, scroll in konqueror without having to look at the right edge of the screen to see if my cursor is on the scrollbar. I could just flip my mouse to the side and scroll.....
sigh.
well, you can allways hope..! :-(
You can disable window decorations in Window menu (Alt+F3) sub-menu Advanced.
I can't remember offhand, but I think
kstart
offers an automated solution for this. Try
kstart --help
Thank you. I had no idea that Special Window Settings dialog existed.
I use Plstik window decorations and it really maximalizes windows.
I use Plastik window decoration and it hides the border at maximalization. (Try to scroll with the mouse in xterm on the border and on the edge after maximalizing.) Maybe the problem is with the application? (E. g. Konqueror itself has a border.)
Same with baghira. No border, also with konqueror.
there are three aspects to this problem:
a) the window decoration needs to "get out of the way" on maximized windows. most window deco themes do this now.
b) the window manager should allow non-bordered windows and remove the window decoration from the equation on request; kwin (and most others) allow this
c) the application needs to avoid adding internal borders/frames at the window edges that get in the way. there is nothing the window manager can do about this one.
and (c) is what you are running into. the tab widget in qt3 has a real problem here where it insists on putting a border there.
so you're right that kwin can't do this, but that's because kwin, or any other wm, can't.
With Konqueror you can press Ctrl+Shift+F to make it fullscreen without borders.
That can already be done - I'm surprised no one told you how -
A window can be in one of four states
1. minimised
2. "restored"
3. maximised
4. full screen.
I think what you are asking for is a way to reach the fourth state. Well, the window menu, in the "advanced" submenu, has a "full-screen" option. I set up a shortcut for that (alt-enter - there's no default shortcut, however).
One way to set up a shortcut is in the kde control center, region and accessibility -> keyboard shortcuts. In the first tab (global shortcuts), in the "windows" group you have the "full screen" entry.
(By the way, don't say "one thing kwin cannot do" when that's not true, at least add a "I think").
Easy.
K-Menu > Control Centre > Desktop > Window Behaviour > Moving
and de-select 'Allow moving and resizing of maximised windows'.
There, wasn't too hard, was it?
No matter what you do you (disable "Allow moving and..." or F11 fullscreen) you still end up with a couple of pixels right to the scrollbar.
You should be able to just move the cursor to the right edge of the screen to use the scrollbar. Right now, this is not possible.
Not exactly. On Kubuntu with Baghira as decoration, my Konqueror have no such burder, if he is maximized. Only in 'normal' mode, there is such a border.
Here is a little Screenshot of a maximized Konqueror (the active window in the back) and a normal Konqueror (the little window in front). As you can see, there is no border beside the scrollbar of the maximized window, but a gray at the small window.
I use a dirty hack to correct this annoying issue....
Use window specific settings to force the window to be displayed with the scrollbar at the edge of the screen. The only option that seems to work is 'force' while for 'apply initially' and 'remember', the setting is not applied on new windows for some weird reason...
Although KDE support d&d (drag and drop) but KWin fails KDE applications by making it impossible to do drag&drop.
because the focus changes to the window as soon as the mouse button is pressed (clicked and held), which makes it impossible to do drag and drop in KDE.
whereas, in windows, when the user releases the mouse button only then the "focus" shifts to the window.
Try for yourself:
1. open konqueror file manager or Dolphin (first window)
2. maximize the first window
3. open another instance of konqi or dolphin (second window)
4. but do not maximize it.
5. Now, try dragging a file from the "maximized" first window to the "unmaximized" second window.
6. as soon as you click on the file in the maximized window the focus is given there and lo and behold! your whole idea of drag&drop is destroyed.
it was reported in KDE 3.3 by me, and this thing is
fixable.. just use "release to focus" instead of "click to focus."
Will KDE 4 really support d&d which works???
> it was reported in KDE 3.3 by me, and this thing is
> fixable.. just use "release to focus" instead of "click to focus."
With KDE 3.5, there is some advanced configuration for this things. I does'nt the English name for modul, but it must be something like 'windowattributes', where you can also configure the click-behavior.
Well if you set Focus follows mouse that will work fine, lets hope they fix it compleately for KDE4 :)
I didn't yet think of it, but now after you mentioned it: It really bugs...
But I think it should be amended: "focus on release + focus on hold for more that 5 seconds" so I can still get a window to the front where I have some folder below my current window.
This kind of drag and drop works with tabs in Konqueror, which has a nice smart behaviour if you drag an item over the tab, so it works as expected. It's also less work (e.g. to manage the windows) than having multiple windows.
Sadly, the developers are reluctant to implement these tabs known from Konqueror in Dolphin.
7. press "ALT-TAB" to bring the "unmaximized" second window to the top
8. Drop
As soon as I click on a window, I expect it to be active and on the top. So that's exactly the behaviour I'd expect.
me too
i do it ike this: drag and hover in the task bar and the application comes into focus and that all there is to it...
hehe, that's exactly what my self-created taskdock do. I think with kde4 and plasma+kross, there will come a huge wave of alternative task bars and docks, because, with scripting-lang this is really easy.
> i do it ike this: drag and hover in the task bar and
> the application comes into focus and that all there is to it...
I like the Mac OS X way even more:
- just drop it on the taskbar item (the dock icon).
The application opens the file automatically with it's default settings. No need to wait to have the window in focus if you want the default behavior.
Yes, event hat I don't use a Mac, this is the expected behavior almost any user would think of at a first time.
On my KDE it's possible actually : just try to drag&drop a Konqueror tab to the konqueror icon of your kicker shorcut bar.
Another thing i like is that when dragging, you can wait over a task bar item, it will give the focus to the app and you'll be able to drop it where you want.
First: Use ALT-TAB to bring on top the window that is behind the maximized one.
Second: Drag files to the button of the second windows where you want to drop, but wait a few senconds. The window will pop up and you will be able to drop files.
Your problem is not big enoguth to say that KWin makes imposible to drag & drop on KDE, or that the whole idea of drag&drop is destroyed.
If you try to drag and drop in this specific way, it doesn't work!
Answer: don't do it that way.
I sympathize; it took some getting used to, but there are plenty of workarounds suggested. It's certainly not something that should be changed by default. *Maybe* an option somewhere.
> If you try to drag and drop in this specific way, it doesn't work!
Works fine for me, this way, with the correct configuration, at kde 3.5.7.
But, I agree, the config for such a behavior is'nt really useful for daily work.
There are workarounds, but the real thing is that this won't ever work - the way X.org works makes it impossible (according to the kwin developers, that is).
I do find it unfortunate, but :(
X have support for this!!
a focus can rise the window or not, most people expect that to happen, but there are several WM that allow it... fluxbox is one of then, it have a option "click to rise"... as soon you click on a window, it rises (the focus is another option), so disabling this will allow one to click and work on a window that is below another one... i maybe wrong, but i think i saw one option in kwin to not "rise on focus/mouse button" when i used it
higuita
Actually, I prefer the "focus follows mouse" policy. That way, there is no problem with drag and drop (as opposed to bloody window$, which bring the window to the top when it is clicked. No way to simply _activate_ a window, while keeping it behind, where it was the whole time :(. Now THAT'S annoying.)
Uhm, I don't know where you get the idea from, but drag'n'drop works fine for me... Just one tiny thing you must change:
KDE control center-> Desktop -> Window behavior -> Window actions (tab)
and there is an option titled "Inactive inner window - Left button".
Change that to "activate & pass click" instead of "activate, raise & pass click".
You can find gentoo-packages of KDE 4 and a guide for installing in the gentoo overlay-wiki:
http://overlays.gentoo.org/proj/kde/wiki
Could someone from here with a youtube account posts some comments?
I just saw the wavy-windows effect (via youtube-dl and mplayer) and I rather liked it, since it would make a great screensaver.
Many of the people there seem to just think "not what I know" or "doesn't work for what I want it for, therefore it's useless" or similar, and I think that the videos should get some really fair feedback.
In the first screenshot... Why is the "Configure window effects"-field wider than the field (the one with "PresentWindows", "blur" etc.) beneath it? A tiny nitpick, I know, but I think that details like that are quite important (and quite easy to fix).
Hi, I'm very impressed with the progress KDE 4 is making - keep it up!
Just wondering about KDM (the theme manager from http://www.kde-apps.org/content/show.php?content=22120) - apparently it is being integrated into KDE 4? What's the latest? Will the theme manager be as easy to use as GNOME's (i.e. drag-and-drop the theme file into the manager and it's ready to go)? How will it interact with kwin_composite and plasma? I really hope theming becomes easier with the next KDE release.
Good luck with everything,
Jan
kdm is not a theme manager, its kdes login application. the link you posted is only used to choose a theme for kdm, not kde.
also, kde3.5 allready has a theme manager (to be found under appearance and themes in controll center) that makes it possible to to configure desktop-background, colors, widget theme, icons, fonts and the screensaver with one file.
so it works exactly like gnome. the only difference is that gnome users tend to produce more "theme-files" than "widget-theme-engines", and kde users do the opposite.
because widget-engines are compiled programs, they should be installed by the packagemanager of your distribution.
I'd be happy if they just made it easier to configure KDM from the text files. I still haven't been able to get KDM to do multiple sessions on different local X servers. GDM does this quite nicely with a little editing of the config file.
Yet another great article Troy
Great work Kwin devs and the rest of the KDE4 devs - KDE4 is shaping up to be something quite amazing!