d4e929fce4
svn path=/trunk/KDE/kdebase/workspace/; revision=761263
248 lines
15 KiB
Text
248 lines
15 KiB
Text
KWin release notes for KDE4.0
|
|
=============================
|
|
|
|
= Introduction =
|
|
|
|
KWin, the standard KDE window manager, in KDE4.0 ships with the first version
|
|
of built-in support for compositing, making it also a compositing manager.
|
|
This allows KWin to provide advanced graphical effects, like for example with Compiz,
|
|
while also providing all the features from previous KDE releases (such as very good
|
|
intergration with the rest of KDE, advanced configurability, focus stealing prevention,
|
|
well-tested window manager, robust handling of misbehaving applications/toolkits, etc.).
|
|
Unlike Compiz, KWin still functions even when no system support for compositing is
|
|
available, with only compositing features not being available in such case.
|
|
|
|
Previous KWin versions in later KDE3.x releases included a standalone compositing
|
|
manager called kompmgr, based on the xcompmgr compositing manager. Kompmgr was only
|
|
loosely tied with KWin, used only XRender for rendering and provided only basic
|
|
features like transparency, shadows and fade in/out animations. Compositing manager
|
|
in KWin in KDE4.0 is integrated with the rest of KWin, can use either OpenGL or XRender
|
|
for rendering and has a framework for compositing effects, all these allowing KWin
|
|
to provide a much wider range of features.
|
|
|
|
Note, however, that compositing support in KWin in KDE4.0 is still considered experimental,
|
|
for several reasons. System support for compositing is often being problematic (various bugs
|
|
in X, drivers or other parts of the system), manual configuration of X may be required
|
|
for proper results (see below), some applications may not be prepared and work well
|
|
with compositing, the performance may not be adequate, and other problems.
|
|
Also, while KWin's compositing support is considered usable and reasonably stable, it
|
|
is relatively new code and has been tested only on a limited range of hardware.
|
|
|
|
Therefore, compositing support in KWin is disabled by default, and needs to be explicitly
|
|
enabled. If there will be any problems, you can disable it again (see below for troubleshooting)
|
|
and report a bug with all relevant information about the problem.
|
|
|
|
|
|
= Setting up =
|
|
|
|
Compositing support is enabled in KWin's configuration. Press Alt+F3 and select 'Configure Window
|
|
Behavior'. In the configuration module, select page 'Desktop Effects' and enable checkbox
|
|
'Enable desktop effects'. After accepting the changes, a dialog with a timeout will appear,
|
|
asking to confirm enabling of compositing support. If you do not confirm within the timeout,
|
|
compositing support will be disabled again, therefore, if enabling compositing triggers
|
|
any problems, it should be sufficient to wait several seconds before the changes are reverted.
|
|
Note that after enabling or disabling compositing it is recommended to restart your KDE
|
|
session in order to ensure that all applications detect the change.
|
|
|
|
If you cannot enable desktop effects, it may be because either your KDE is not built
|
|
with necessary support, or more probably because your system is not capable of providing
|
|
compositing support. See file
|
|
http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/kwin/COMPOSITE_HOWTO
|
|
for some instructions on setting up your system. Note that there may be other factors
|
|
affecting whether you do or do not have compositing support.
|
|
|
|
|
|
= Usage =
|
|
|
|
A quick overview of features provided by compositing manager in KWin:
|
|
|
|
- Ctrl+F9 (and Ctrl+F10 for windows from all desktops) shows an overview of all windows
|
|
and allows activating one of them. The feature can be also activated by moving the mouse
|
|
into the top-left screen corner. A window can be activated by clicking it or by using arrows
|
|
and Enter key. You can also type text to filter the list of windows.
|
|
- Ctrl+F8 shotcut activates a desktop grid - all your virtual desktops will be arranged
|
|
on the screen (as an enlarged pager) - you can select and activate desktops using
|
|
a number, a function key, by clicking on it or by using arrows and Enter key,
|
|
you can move windows by dragging them or by right-clicking on them.
|
|
- The DesktopGrid effect also provides animations when switching between virtual desktops (can
|
|
be turned off).
|
|
- The window switcher (Alt+Tab by default) provides live thumbnails of windows.
|
|
- Windows blocked by modal dialogs are dimmed.
|
|
- Screen can be zoomed in and out using Win+<equals>, Win+<minus> and reset using Win+0 (
|
|
it is currently not possible to use mouse wheel, but this feature is planned). Note that
|
|
because of input transformation not being yet available in X the zoomed screen has to move
|
|
around to keep the mouse pointer at the same place like it would be when not zoomed.
|
|
- Screen can be shown with inverted colors by pressing Ctrl+Win+I (accessibility feature,
|
|
Invert effect is not enabled by default).
|
|
- There are fade animations during login and logout.
|
|
- Windows fade in and out.
|
|
- Minimize animation to/from taskbar.
|
|
- Windows have shadows.
|
|
|
|
There are more features that are not enabled by default and need to be explicitly enabled
|
|
in the configuration.
|
|
|
|
There are various videos showing various compositing features of KWin. For example,
|
|
search for 'kwin_composite' at youtube.com (please keep in mind that many of those windows
|
|
are old and show testing or demo effects).
|
|
|
|
|
|
= Using KWin without KDE desktop =
|
|
|
|
Just like with older KWin versions it is possible to use KWin also with other desktop
|
|
environments or even as a standalone window manager, as long as required KDE libraries
|
|
are installed. Please note that KWin is a pure window manager and does not provide a panel
|
|
or handle desktop background like some window managers do. KWin's compositing features
|
|
work in the standalone mode, with some functionality missing (because of missing taskbar,
|
|
for example), and, while this has not been tested, it is expected that compositing
|
|
features will work also when running in other desktop environments, possibly with some
|
|
functionality missing again. Reports on using KWin with other desktop environments
|
|
are welcome.
|
|
|
|
|
|
= Performance =
|
|
|
|
Compositing internally works by redirecting window drawing to offscreen memory and composing
|
|
it on the screen in an additional drawing pass. This means that in general composited desktop
|
|
on average has worse performance that non-composited desktop (although in some cases it
|
|
may perform better, be that real improvement or just perceived one due to animations, better
|
|
synchronization or similar factors). For example, binding window pixmaps to OpenGL textures
|
|
(that is, preparing window contents for drawing) can be a relatively costly operation
|
|
with large windows, making things like animations in Plasma desktop window or page scrolling
|
|
in a maximized browser window jerky. Heavy system load can also cause the compositing manager
|
|
not repaint often enough, resulting in lagging or jerky screen redrawing.
|
|
|
|
KWin in KDE4.0 is also relatively new code and has not been extensively optimized yet,
|
|
therefore its performance may not be in some areas comparable with performance of other
|
|
compositing managers. In such cases performance should be improved with newer versions.
|
|
|
|
Note that current XRender implementations (in X/drivers) often perform rather poorly and
|
|
therefore the OpenGL mode usually should have much better performance. See below for notes
|
|
on XRender mode.
|
|
|
|
Tip: Performance/smoothness with nVidia cards: Smoothness of KWin rendering
|
|
can be improved by setting env.variable KWIN_NVIDIA_HACK to 1 (e.g. append
|
|
"export KWIN_NVIDIA_HACK=1" to your ~/.profile file). This sets __GL_YIELD=NOTHING
|
|
for KWin, letting KWin use more CPU time for OpenGL operations, however
|
|
at the expense of affecting performance of other applications. This is
|
|
therefore disabled by default. This setting may be removed in the future
|
|
if the negative impact becomes insignificant. See section "OPENGL YIELD BEHAVIOR"
|
|
in README.txt for nVidia cards.
|
|
|
|
|
|
= Troubleshooting =
|
|
|
|
As already said, compositing support in KWin is considered usable and reasonably stable,
|
|
but due to several reasons it may not work properly for you.
|
|
|
|
If there are any problems with compositing support, the simplest option is to disable
|
|
it again. KWin will normally continue functioning, only not providing compositing features.
|
|
If you cannot normally turn off compositing support (for example because the screen
|
|
is corrupted), you can turn it off using one of these ways:
|
|
- run command 'kwriteconfig --file kwinrc --group Compositing --key Enabled false' from
|
|
the command line
|
|
- set environment variable 'KWIN_COMPOSE' to 'N' (append 'export KWIN_COMPOSE=N' at the end
|
|
of your ~/.profile), this affects compositing only temporarily
|
|
You will probably need to switch to text mode or start failsafe session from KDM to be
|
|
able to perform this.
|
|
|
|
See file http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/kwin/COMPOSITE_HOWTO
|
|
for some issues with various graphics cards.
|
|
|
|
|
|
= XRender mode =
|
|
|
|
It is possible to use XRender for compositing instead of the default OpenGL.
|
|
XRender mode in general has less features, however at the moment it is also considered
|
|
unstable - it has not received as much testing as OpenGL mode, some features may be incomplete
|
|
and it is recommended to use the OpenGL mode if possible. Also note that current XRender
|
|
implementations (in X/drivers) often perform rather poorly.
|
|
|
|
|
|
= Developers =
|
|
|
|
KWin provides support for writing compositing effects that may be loaded into KWin as
|
|
plugins. These effects communicate with KWin core using C++ API specially designed for this
|
|
purpose, making effects not directly dependent on KWin core and changes in it.
|
|
|
|
At the time of the KDE4.0 release, since compositing support is still under heavy development,
|
|
this API is considered unstable and subject to change. If you write your own effect plugin,
|
|
you may need to recompile it after KWin update. KWin will however detect incompatible
|
|
versions and will not load such plugins (automatic, you do not need to provide any code for it).
|
|
As the compositing support will become more stabilized, this API will be kept backwards and
|
|
binary compatible, just like with other KDE libraries.
|
|
|
|
At the time of the KDE4.0 release, API for compositing effects is unfortunately only sparsely
|
|
documented. Developers interested in writing compositing effects for KWin are suggested
|
|
to use source code of effects shipped with KWin (the Howto effect as the starting point)
|
|
and/or ask on the KWin mailing list.
|
|
|
|
Links to various KWin-related documents are available at http://techbase.kde.org/Projects/KWin .
|
|
|
|
= FAQ =
|
|
|
|
== Why not Compiz? ==
|
|
|
|
It is possible to use Compiz instead of KWin with KDE, however KWin remains the default window manager.
|
|
The option of replacing KWin with Compiz had been evaluated before work on compositing features
|
|
of KWin started and the conclusion was, in short, that it would lead to a lot of work and duplicated
|
|
effort.
|
|
|
|
To answer in more detail, several technical things need to be explained. Both KWin and Compiz
|
|
are a combined window manager and compositing manager. Window manager functionality takes care
|
|
of all aspects of handling windows, such as their placement, selecting the active one as so on.
|
|
This functionality is crucial for a desktop - without a window manager it would be very difficult
|
|
to perform most operations with windows. Compositing manager functionality, on the other hand,
|
|
can be considered optional - while it brings many new features, it is still possible very well
|
|
to use a desktop (such as with KWin in KDE3).
|
|
|
|
The reasons to add compositing support to KWin instead of using Compiz include:
|
|
|
|
- Compiz at the present time is very likely the most advanced compositing manager with many features,
|
|
with a headstart when compared with KWin, however, this cannot be said about Compiz as the window manager,
|
|
where KWin has the advantage of being a much more tested codebase, providing more stable, well-tested
|
|
and robust window manager, with many features. Given that, as said above, window manager functionality
|
|
is considered to be more important, it would be unwise to force all KDE users to a change that
|
|
would likely mean regressions in many aspects.
|
|
|
|
These regressions would include lesser integration with KDE, visual and behavioral changes
|
|
(the 'KDE window decorator' shipped with Compiz only mimics the look of KWin's decorations,
|
|
but does not provide the same functionality, even the Alt+F3 popup menu visibly differs),
|
|
possible introduction of problems that have already been fixed in KWin, missing features
|
|
that have already been implemented in KWin, and so on. Developing, testing and bugfixing a window
|
|
manager can be a very demanding work and repeating all the work done on KWin again for Compiz would
|
|
presumably require a lot of effort. As such, claims that KWin is 'reinventing the wheel' are missing
|
|
the point, since Compiz, being a relatively new window manager, is reinventing at least as much,
|
|
if not more, from other window managers including KWin,
|
|
|
|
Also, given that there can be only one window manager and one compositing manager at a time,
|
|
there would not be possibly a way to remedy these problems by somehow running Compiz and KWin together.
|
|
|
|
- Compiz currently does not work at all when compositing is not possible, thus requiring a fallback
|
|
window manager for such case. This in practice would mean that KDE developers would be required
|
|
to work on improving Compiz and would have to keep KWin at least for maintenance as the fallback
|
|
for Compiz, thus having two window managers for KDE. Besides the developer work of taking care
|
|
of two window managers this would also bring many user problems resulting from two different
|
|
window managers, with differences in the look and feel, feature sets and bugs.
|
|
|
|
It should be also noted that Metacity, GNOME's window manager, has not been dropped in favour of Compiz
|
|
either, but is still, to our knowledge, under development and adding compositing features to it
|
|
is a work in progress.
|
|
|
|
|
|
== Why not use plugins from Compiz? ==
|
|
|
|
This option was considered in the past as well. After examination of Compiz code the conclusion was
|
|
that this is technically almost impossible. Compiz plugins appear to be merely parts of Compiz
|
|
that are separated from its core, but which still heavily depend on it - there are even plugins
|
|
that appear to copy and paste parts of Compiz core and modify it. Making it possible to use such
|
|
plugins from KWin would essentially require KWin to become Compiz.
|
|
|
|
|
|
== Why add compositing support to KWin when Compiz is better ? ==
|
|
|
|
There can be different ideas about what better means, but regardless of that, the main aim of KWin
|
|
is not to replace Compiz. Many users have asked for compositing support in KDE, and, as explained
|
|
in 'Why not Compiz?', the best way to achieve that is considered to be adding compositing
|
|
support to KWin. KWin aims to provide compositing support, focusing on providing useful compositing
|
|
features and basic visual effects, while keeping its other strengths.
|