diff --git a/NOTES_4_0 b/NOTES_4_0 deleted file mode 100644 index 7b36ead261..0000000000 --- a/NOTES_4_0 +++ /dev/null @@ -1,248 +0,0 @@ -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+, Win+ 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.