KDE TechBase - User contributions [en]

Getting Started/Build/KDE4

2009-09-16T15:43:55Z

Mwoehlke: s/qt-copy/kde-qt/, remove HAL (never had complete instructions)

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/KDE4}}

{{TutorialBrowser|

series=Getting Started|

name=Building KDE4 (Development version, TRUNK) From Source|

pre=[[../../Sources/Anonymous_SVN|Anonymous SVN Quickstart Guide]]|

next=[[../../Set_up_KDE_4_for_development|Set up KDE 4 for development]]|

reading=[[../kdesvn-build|kdesvn-build: The KDE From Subversion Build Tool]] [[Contribute/Send Patches|Contributing/Sending Patches]] [[../../Increased_Productivity_in_KDE4_with_Scripts|Increased Productivity in KDE4 with Scripts]] [[Development/Tutorials/CMake |Introduction to CMake]] [[../KDE4/FreeBSD|FreeBSD notes]] [[../KDE4/Mac OS X|Instructions for Mac OS X]] [[../KDE4/Windows|Instructions for MS Windows]]|
}}

== Abstract ==

This tutorial shows one way to get KDE from trunk running on Linux/BSD systems. There are also tutorials for [[Getting_Started/Build/KDE4/FreeBSD|FreeBSD]], [[/Windows|Windows]], [[/Mac OS X|Mac OS X]] and [http://solaris.kde.org/ Solaris]. This tutorial creates a special user, kde-devel, that will run KDE trunk. On the one hand, this allows other users to continue with another KDE version. On the other hand, testing special system-wide code like the KDE display manager is not possible. There is a tutorial to
[[Getting_Started/Build/KDE4/onVmWare|set up KDE 4 trunk on a virtual machine]].

Throughout the tutorial the bash shell is used.

{{warning|Expect a higher risk of build failure '''on Mondays''' when most kdelibs changes are committed. [http://developer.kde.org/~dirk/dashboard/ Dashboard] reports unexpected breakages. You are encouraged to fix failing modules.}}

== Create a user account for KDE4 development ==

{{Note|
Some people like to have a separate user account for KDE 4 (for instance an old bug deleted files by mistake), and the instructions below were written with that approach.

However it is much more efficient to do everything with a single user account, see [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts|Increased Productivity in KDE4 with Scripts]]
for more details.

You can still follow the instructions below, but don't put the environment variables in your <tt>.bashrc</tt>, put them in a separate file that you source to switch to the KDE 4 environment.
}}

=== Option 1: Command Line ===
{{Note|
On some systems a new user is configured by default to use {{path|/bin/sh}}. Using {{path|/bin/sh}} can be very inconvenient to work with and you may want to change it to {{path|/bin/bash}} or another shell.
On Ark Linux and Fedora, you can skip the <tt>-s /bin/bash</tt> switch - {{path|/bin/sh}} is {{path|bash}}.
}}
<code bash>
useradd -m kde-devel -s /bin/bash
passwd kde-devel
</code>

{{Warning|
The new kde-devel user will not be added automatically to all the user groups, which will result in not having sound, not being able to sudo, etc. Edit your /etc/groups file to add the kde-devel user to all the groups that you need (probably the groups that your usual username is already assigned to).
}}

=== Option 2: Using KControl ===

Instead of using the commands above, you can also use the User module in the KDE Control Center if you already have KDE3 installed.

=== Setting up the environment ===

Copy the {{path|~/.bashrc}} from your normal user account to the new kde-devel account. Next, copy and paste the contents of the [[Getting Started/Increased Productivity in KDE4 with Scripts/.bashrc|example .bashrc]] into {{path|~kde-devel/.bashrc}}. Be sure to comment out the line <tt>alias make=makeobj</tt> if you do not have the <tt>[[Getting Started/Build/KDE4#Required Software|makeobj]]</tt> command available. Alternatively, you can download the kde-sdk package (or perform a subversion checkout) and include the kde-sdk/scripts/ directory in your path. You will probably also want to modify the path to make sure it doesn't include your kde3 paths. Also if you want to use KDevelop to develop KDE 4 applications you may pass the ''-GKDevelop3'' flag to the ''cmake'' command (to make CMake generate KDevelop project files, it will help to avoid rebuilding in the future, see [[Getting_Started/Set_up_KDE_4_for_development#Setting_up_the_environment|this]]).
To make it run, you have to open a new bash or to execute
<code bash>
source ~/.bashrc
</code>

This will provide access to commands such as <tt>cmakekde</tt> that are used in this tutorial as well as ensure that the proper paths are in place for Qt, KDE and CMake binaries.

For more information, please read the [[Getting Started/Increased Productivity in KDE4 with Scripts]] tutorial.

=== Switching to the New User ===
Switch to the user kde-devel:
<code bash>
ssh -X kde-devel@localhost
</code>

{{Note|
If the ssh command fails, check out the [[Getting_Started/Set_up_KDE_4_for_development#Launching_KDE_4_apps|Launching KDE 4 apps]] section of the [[Getting_Started/Set_up_KDE_4_for_development|KDE4 development guide]].
}}

== Required packages from your distribution ==
The requirements to build kde4 from source vary from distribution to distribution. Instructions for your distribution are provided below:

* [[Getting_Started/Build/KDE4/Ark Linux|Ark Linux]]
* [[Getting_Started/Build/KDE4/Arch Linux|Arch Linux]]
* [[Getting_Started/Build/KDE4/Fedora|Fedora]]
* [[Getting_Started/Build/KDE4/Kubuntu and Debian|Kubuntu and Debian]]
* [[Getting_Started/Build/KDE4/openSUSE|openSUSE]] Note: there is a [http://en.opensuse.org/KDE/Developing/Guide specific guide for openSUSE]. However be careful because it updates a huge number of your stable packages.
* [[Getting_Started/Build/KDE4/Gentoo|Gentoo]]
* [[Getting_Started/Build/KDE4/LFS|Linux from Scratch]] or to build from source.
* [[Getting_Started/Build/KDE4/Mandriva|Mandriva]]

* [[Getting_Started/Build/KDE4/Generic|any other distro]]

Your next compilation step depends on the packages supplied by your distro.

=== Compiling kde-qt, etc. ===
If you do not want to use the packages provided by your distro you can compile things like Qt yourself. Instructions for building all dependencies including CMake, Qt4 (kde-qt) and kdesupport are available in [[Getting_Started/Build/KDE4/Prerequisites|the build prerequisites page]]. Note that automoc, phonon, strigi, soprano, and a few other things are part of kdesupport, so if you have errors about these missing, you'll need to get kdesupport.

== Building KDE for development or stable use ==

The commands below are used to build the latest unstable version of KDE from trunk. This should not be used in a production environment, but is recommended for developers.

To build the stable version of KDE4, change the svn checkout commands below to <tt>branches/KDE/4.3/</tt> instead of <tt>trunk/KDE/</tt>, ie:

svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.3/kdelibs
svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.3/kdepimlibs
svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.3/kdebase

etc...

== kdelibs ==

We can now move on to building KDE's base libraries.

=== The Recipe ===
cd
cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
mkdir KDE && cd KDE
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
cd kdelibs
cmakekde

=== What's Happening ===
We change to the base source directory (line 1) then make and go into the KDE directory (line 3). We download the sources for kdelibs using subversion (line 4), go into the new {{path|~/kde/src/KDE/kdelibs}} directory (line 5), and commence the build (line 6). This will leave us in the <tt>kdelibs</tt> build directory after the build is completed.

{{tip|There might be missing dependencies on your system! They are easily overlooked in the output of <tt>cmakekde</tt>.
You might want to do a <tt>cmake $KDE_SRC/KDE/MODULE_NAME</tt> prior to compiling any kde modules (like kdelibs, kdepimlibs etc.)}}

=== Additional KDE-specific CMake know-how ===

There are additional CMake modules in {{path|kdelibs/cmake/modules/}} that are necessary for building KDE4 applications. These will be installed for you when kdelibs itself is installed.

To make a non-debug-release (e.g. suppressing all kDebug() messages), use e.g.
cmake -DCMAKE_BUILD_TYPE=Release . && make && make install

=== Troubleshooting ===

For troubleshooting information, see the [[Getting_Started/Build/KDE4/Troubleshooting#Issues_building_kdelibs|kdelibs troubleshooting section]].

== kdepimlibs ==
Currently kdebase depends on kdepimlibs so it is required to install it first. These libraries are also shared by other packages such as those within kdepim, kdeutils and kdenetwork.

=== libical ===
Download libical from http://sourceforge.net/project/showfiles.php?group_id=16077, compile, link and install it.
tar xvzf libical-0.41.tar.gz
cd libical-0.41
./configure && make && make install

=== The Recipe ===
cs KDE # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepimlibs
cd kdepimlibs
cmakekde

=== What's Happening ===
We go into the KDE source directory (line 1), download the source code for kdepimlibs using subversion (line 2) and then go into the new {{path|~/kde/src/KDE/kdepimlibs}} directory (line 3). We then commence the build (line 4). This will leave us in the <tt>kdepimlibs</tt> build directory after the build is completed.

=== Troubleshooting ===

For troubleshooting information, see the [[Getting_Started/Build/KDE4/Troubleshooting#Issues_building_kdepimlibs|kdepimlibs troubleshooting section]].

== kdebase ==
kdebase is divided into three parts:
* '''apps'''
:This contains applications like Dolphin or KWrite.
* '''runtime'''
:This contains things needed by every application at runtime, like icons. It is a required dependency for each KDE application, so you have to compile and install this.
* '''workspace'''
:This contains things specific to the KDE desktop, like Plasma or the window manager. Most stuff here depends on X11. You only need it if you want to build a full KDE desktop.

You can build all of kdebase at once, which is described in the recipe below. If you only want to build kdebase-runtime, which is the only requirement, you can replace <code bash>cd kdebase</code> with <code bash>cd kdebase/runtime</code> in the recipe below.

=== The Recipe ===
cs KDE # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
cd kdebase
cmakekde

=== Troubleshooting ===
For troubleshooting information, see the [[Getting_Started/Build/KDE4/Troubleshooting#Issues_building_kdebase|kdebase troubleshooting section]].

== Translations ==

Most KDE users are going to install translations before being able to use their desktop properly. Full information is given in the Localisation tutorial at [[Development/Tutorials/Localization/Building_KDE's_l10n_Module]].
For a single language, the following receipe installs messages and translated documentation:

=== The Receipe ===
cs KDE # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout -N svn://anonsvn.kde.org/home/kde/trunk/l10n-kde4
cd l10n-kde4
svn checkout scripts <language>
./scripts/autogen.sh <language>
cd <language>
cmakekde

== Running KDE 4 programs ==

You can now run KDE 4 programs (e.g. kwrite) by typing:
ssh -X kde-devel@localhost
kwrite

=== Troubleshooting ===

For troubleshooting issues see [[Getting_Started/Build/KDE4/Troubleshooting#Running_programs|troubleshooting running programs]].

== Generating local API documentation ==

See the [[Development/Tools/apidox|generating apidox]] page.

== Staying up to date ==

In order to keep the kde4 installation up to date, each of the modules installed should be updated periodically. As Monday is the day for big changes in kdelibs, Tuesday may be the best day to do this. For each module checked out, run <tt>svn up</tt> and <tt>make</tt>.

For example:
<code bash>
cs kdesupport # cs is not a typo
svn up
cb # cb is not a typo
make install
</code>

Note: it is not necessary to run cmakekde for updates.

== Installing a subset of a module ==

Many modules in KDE contain a large number of programs which could take a long time to download and compile. In cases where you want to work only on a particular program or programs in a module, it is possible to download and compile particular folders. In some cases, certain folders are required for any build of the module. This is determined in the CMakeLists.txt file of the module. For example the [http://websvn.kde.org/branches/KDE/4.0/kdegames/CMakeLists.txt?view=markup kdegames CMakeLists.txt file] lists:

<code>
add_subdirectory(libkdegames)
add_subdirectory(libkmahjongg)

macro_optional_add_subdirectory(doc)
macro_optional_add_subdirectory(lskat)
macro_optional_add_subdirectory(katomic)
</code>

So, the libkdegames and libkmahjongg directories are required to build any of kdegames. The cmake directory will also usually be required. All the other directories (doc, katomic etc) are optional. They will be built if present on your machine. In this example, we build kmahjongg and kbattleship:

<code bash>
cs KDE
svn co -N svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames # The -N switch performs a non-recursive checkout
cd kdegames
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/libkdegames # Get required directories
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/libkmahjongg
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/cmake
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/kbattleship # Get optional directories
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/kmahjongg
cmakekde
</code>

== Success! ==

You are now ready to start building other svn modules in the same fashion as you built kdebase, running and testing KDE4 or writing your own patches and applications.

For further isolation of your development environment change symbolic links, which you will see after executing ls -lh $(kde4-config --localprefix), assuming newly installed kde4-config is called.

See the [[Getting Started/Set up KDE 4 for development|Set up KDE 4 for development]] tutorial for how to start KDE 4 applications and how to use KDevelop to work on them.

For most of what you need to know on patches see: [[Contribute/Send Patches|Contributing/Sending Patches]]

[[Category:Build KDE]]
[[Category:KDE4]]

Archive:Getting Started/Build/Requirements

2009-09-14T18:47:06Z

Mwoehlke: replace qt-copy references with kde-qt

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/KDE4/Prerequisites}}

{{TutorialBrowser|

series=Getting Started|

name=Building KDE4 From Source/Prerequisites|

pre=[[../|KDE SVN Quickstart Guide]]|

next=[[../|KDE SVN Quickstart Guide]]|
|
}}

== Abstract ==

Some or all of these packages should be available for installation from your distribution. For ease of installation and upgrading it is a good idea to install distribution packages if a recent enough version is provided. Software required to build KDE4 includes:

* gcc and g++, preferably version 4.2 or higher
* svn, the subversion revision control client
* pkg-config
* development libraries and headers for X11, OpenGL (mesa-common-dev and libglu1-mesa-dev), libjpeg, libpng, libungif, [http://clucene.sourceforge.net/index.php/Downloads libclucene], [http://download.librdf.org/source/ librdf], libxml2 and libxslt
* the <tt>makeobj</tt> script, which is included in kdesdk. You can install it from kdesdk (kdesdk-scripts on Debian) or similar packages, or download at [http://websvn.kde.org/*checkout*/trunk/KDE/kdesdk/scripts/makeobj WebSVN]
* the [http://freedesktop.org/wiki/Software/shared-mime-info shared-mime-info package], is the freedesktop MIME standard now used in KDE
* [http://boost.org/ boost], used by kdebase; after build and/or install, in order to make cmake aware about its location (FindBoost), add the boost directory (which contains the include subdirectory) to CMAKE_INCLUDE_PATH or set a environment variable called BOOST_ROOT that points to the boost directory.

== D-Bus ==
QtDBus and KDE are known to work with D-Bus versions 0.62, as well as 0.92 and upwards. Versions 0.60 and 0.61 may work too but are not tested. Versions 0.90 and 0.91 are known not to work. We recommend using post-1.0 release versions (at least 0.94), so consider upgrading if you haven't done so.

You may skip this section if you have a recent D-Bus version or if you don't want to upgrade. You probably want to skip building the bindings until/unless you know you will be building HAL (see below).

Before running these steps in the recipe, make sure your X11 headers and libraries are available. The configure script run on line 5 of the following instructions should output:
Building X11 code: yes

=== The Recipe ===

{{tip|Make sure you did set up your environment correctly as described [[Getting_Started/Build/KDE4#Setting_up_the_environment|above]]. This is necessary for the <tt>cs</tt> and <tt>cb</tt> functions to work.}}
(NOTE: on my intrepid installation, I had to additionally set my CFLAGS to '-D_GNU_SOURCE' for this to work)

cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
wget http://dbus.freedesktop.org/releases/dbus/dbus-1.0.2.tar.gz
tar -xvzf dbus-1.0.2.tar.gz
cd dbus-1.0.2/
./configure --prefix=$DBUSDIR --localstatedir=/var
make
sudo make install
sudo dbus-uuidgen --ensure

cs # see above
wget http://dbus.freedesktop.org/releases/dbus-glib/dbus-glib-0.74.tar.gz
tar -xvzf dbus-glib-0.74.tar.gz
cd dbus-glib-0.74/
./configure --prefix=$DBUSDIR
make
sudo make install
cd
sudo chown -R kde-devel:kde-devel *

=== What's Happening ===
After changing into the source directory (line 1), D-Bus source code is downloaded from freedesktop.org (line 2) and unpacked (line 3). After going into the newly created D-Bus directory (line 4), the build is set up using the supplied {{path|configure}} script (line 5). After building (line 6) and installing (line 7) D-Bus, we use the <tt>dbus-uuidgen</tt> tool to install a machine identification file that allows the bus to start automatically when the desktop session starts (line 8).

Note that you need write access to {{path|/var}} for the last two steps. If your system does not have the sudo command, you can use the <tt>su</tt> command instead, e.g. <tt>su -c "make install"</tt>.

The steps for building the glib bindings are similar to the above.

When these two packages are done building, we must fix the file ownership because 'sudo make install' has created root owned files and directories in ~kde-devel/kde.

=== Troubleshooting ===
If you get the error:
"configure: error: DBus development libraries not found"
do this:
export PKG_CONFIG_PATH=/lib/pkgconfig/

== CMake ==
Skip this if you have [http://cmake.org/ CMake] >=2.6.2 installed.
You should be able to directly use the binary packages available on the [http://cmake.org/HTML/index.html CMake site]. There are also distribution specific packages available.

=== The Recipe ===


cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click Here to learn more]]
wget http://www.cmake.org/files/v2.6/cmake-2.6.2.tar.gz
tar -zxf cmake-2.6.2.tar.gz
mkdir cmake-build
cd cmake-build
../cmake-2.6.2/bootstrap
make
sudo make install

=== What's Happening ===
First, we go back to the <tt>kde-devel</tt> user's source directory (line 1), get the CMake sources (line 2) and unpack them (line 3). We create a directory to build CMake in (line 4) and go into it (line 5). We then run the CMake bootstrap script to set up the CMake build (line 6), then make (line 7) and install it (line 8) using the root user.

If your system does not have the <tt>sudo</tt> command, you can instead do <tt>su -c "make install"</tt>.

== Qt ==
Next we need to get Qt4. KDE 4.3 builds against Qt 4.5, however KDE trunk requires Qt 4.6. If you plan to build trunk on an ongoing basis, it is probably easier to track kde-qt, especially as KDE trunk may occasionally require a pre-release version of Qt.

Most up-to-date distributions will have packages of sufficiently new Qt to build the latest KDE stable branch. Some distributions may even package kde-qt; if so, using it is a viable option. If the distribution you use does not provide packages of the necessary version of Qt, it will be necessary to use the recipe below. More information can be found in the sections of the tutorial specific to each distribution.

Building qt4.4 with the -no-qt3support option will cause things to break.

Please read the [http://qt.gitorious.org/+kde-developers/qt/kde-qt/blobs/4.5.2-patched/README.kde-qt README.kde-qt] file for the necessary Qt configure options as well as currently known issues.

=== The Recipe ===
cs # Note: cs is not a typo. See [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|.bashrc]]
git clone git://gitorious.org/+kde-developers/qt/kde-qt.git qt-kde
cd qt-kde
./configure [copy/paste configure line from README.kde-qt replacing <installdir> with $QTDIR]
make -j2 # use 'make -j(X+1)' where X is your number of processors, to compile faster
# if we don't install, we'll just clear obj files to
# save disk space
if [ "$QTDIR" = "`pwd`" ]; then \
find . -name '*.o' -delete ; \
else make install; fi;

'''Make sure <tt>which qmake</tt> delivers something out of $QTDIR, e.g.:'''
/home/kde-devel/qt-kde/bin/qmake

=== What's Happening ===
We switch back to the <tt>kde-devel</tt> user's home directory (line 1) and download the source code, KDE branch, from gitorious using git (line 2). After changing into the resulting {{path|qt-kde}} directory (line 3), we then set up the build using the <tt>configure</tt> script (line 4). The various command line options used are explained in the {{path|qt-kde/README.kde-qt}} file. Finally, we build the minimal requirements for KDE (line 6) and install (line 9) Qt. If install dir is the same as the current dir (line 7), then we just free some space (line 8) instead. If you want all the example and demo applications, you can either build them individually or simply do a <tt>make</tt> from the {{path|qt-kde}} directory.

Note that the installation does not require root as it installs Qt locally into {{path|$QTDIR}}. Installation is necessary if {{path|$QTDIR}} differs from the source directory.
In the end, we make sure the cmake macro to find the Qt directory will work. It must be able to find qmake in $QTDIR.

=== Troubleshooting ===
If you get "error: X11/Xlib.h: No such file or directory", install the devel package of <tt>xorg</tt> (the actual name may vary between operating systems, for example it is <tt>xorg-dev</tt> on Ubuntu based systems such as Kubuntu).

If you get an error in the configure step about missing defines, check the value of <tt>$QMAKESPEC</tt>. Some distributions set this to point directly to the system-installed Qt. If <tt>unset QMAKESPEC</tt> solves the problem, you probably want to add it to the <tt>~/.bashrc</tt> script.

If you get an error ".pch/debug-shared/QtCore", this is because Qt-4.3 enables precompiled headers if your gcc supports it, but for some reason it doesn't work for you. If you use distcc, configure qt with -no-pch. If you use icecream, update to the latest icecream from svn trunk.

Try running any Qt program, like {{program|assistant}}. '''Note:''' You may need to run <tt>xhost +local:kde-devel</tt> as your regular kde3 user to run this application. If it crashes in QSpanData::adjustSpanMethods, then your problem is the oxygen style. Try removing {{path|lib/kde4/plugins/styles/kstyle-oxygen.so}} and {{path|lib/kde4/plugins/styles/oxygen.so}} if they exist in the KDE install prefix.

=== Generating local API documentation ===
It's nice to have the Qt documentation locally for nice integration with [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|KDevelop]], and doing this is really quite easy (also shown in {{path|README.kde-qt}}):
cd $KDE_SRC/qt-kde
make docs
./config.status
make install
Note that it is necessary to do this only once, even if you rebuild Qt later.

== HAL ==

{{tip|You can use qdbusviewer to see if you have org.freedesktop.hal. If not, you might need a newer version of hal. If you have org.freedesktop.hal, you probably don't need to, and don't ''want'' to, roll your own HAL.}}

If your system requires you to build a newer version of HAL, there's a decent chance you'll need to build other stuff as well, some of which may not be straight forward. This, however, should only be required for older distros.

== kdesupport ==

{{warning|Don't forget to read the [[Getting_Started/Build/KDE4#Setting_up_the_environment|Setting Up The Environment]] section first.}}

There are several libraries that KDE applications rely on in the kdesupport module. This includes Phonon, Strigi and Soprano for file metadata and search, QImageBlitz for image manipulation needed in kdebase, eigen for visual effects in applications such as Kalzium, taglib for music players and qca for some cryptographic needs.

Strigi itself has a few dependencies as well: you will need the libraries and headers for libz, libbz2, openssl (libcrypto or libssl), libclucene (>=0.9.16a but watch out: version 0.9.17 does '''not''' work), and either libxml2 or libexpat.

Please remember that if you use openSUSE, you can install the needed packages from the KDE:KDE4 buildservice repository and do not have to bother with fiddling the details below. Skip to the kdelibs section.

=== The Recipe ===

cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/kdesupport/
cd kdesupport
cmakekde

=== What's Happening ===
We change to the base source directory (line 1). We download the sources in kdesupport using subversion (line 2), go into the new {{path|~/kde/src/kdesupport}} directory (line 3), and commence the build (line 4). This will leave us in the kdesupport build directory after the build is completed.

=== Troubleshooting ===
If you get
cmakekde: command not found
then you have to go manually into the kdesupport directory in ~ and execute the command cmakekde. if this still doesn't work, then something is wrong with your bashrc.

If you get
CMake Error: This project requires some variables to be set,
and cmake can not find them.
Please set the following variables:
LIBXML2_INCLUDE_DIR (ADVANCED)
you should install the development package for libxml2.

If you get
CMake Error: Could NOT find REDLAND
then you need librdf from the Redland.
If your distribution does not provide the librdf package, you can download the source there: [http://download.librdf.org/source/ http://download.librdf.org/source/] and build it.
(Gentoo users: The ebuild for librdf is named dev-libs/redland)

If you get
Fetching external item into 'kdesupport/admin'
Error validating server certificate for 'https://...'
see [[Getting_Started/Sources/Using_Subversion_with_KDE|Using Subversion with KDE]]

If you get
FILE cannot create directory: /usr/lib[64]/qt4/plugins/crypto. Maybe need administrative privileges.

make: *** [install] Error 255
take a second look in the .bashrc file described above, are paths correct? ($QTDIR and $PATH are used to get the QT installation path)
Alternatively, you may see this error if you decided to use a distribution installed version of qt4 and skipped the Qt install above. Either install qt-kde as describe above, or "sudo make install". If you use "sudo make install", make sure that you change the ownership back to your user for some of the ~/kde subdirectories that were effected by using sudo (ie. "<tt>sudo chown -R kde-devel:kde-devel ~/kde</tt>").

If you get a message related to
target libQtTest.so not found
you may need to recompile qt-kde. This time you should take out
-nomake demos -nomake examples
from the configure command, so that Qt generates library QtTest.

If you get
CMake Error: Qt qmake not found!
Then:
1) uncomment Qt section in .bashrc script (QTDIR, QT_PLUGINS_DIR,
PKG_CONFIG_PATH variable settings).
2) source ~/.bashrc
3) cd && cd qt-kde
4) make confclean
5) repeat steps for installing Qt (from ./configure line).
6) retry building kdesupport

If you get
"CMake Error: Could NOT find BZip2"
then
sudo apt-get install libbz2-dev
or
urpmi libbzip2_1-devel

If you get
message that MySql support cannot be enabled
then
you need to install corresponding devel package. (libmysqlclient-devel for SuSe 11.1)

== Next Step ==
Once all requirements have been installed it is time to install [[../#kdelibs|kdelibs]]

Projects/Usability/NWI

2009-06-29T21:25:53Z

Mwoehlke: /* Session management */

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to container, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grid Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the grid "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

The desktop and each container type have their own default setting whether they should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Individual containers can also be configured for regular/shared or use the container-type default.

When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Note that typical "hide menubar" option affects only application menu, not shared menu. To hide shared menubar user has to select "hide container menubar" option.

{ MAYBE: in case with shared menu there could be added such container entries like "close window", "create preset", "convert to", "help", so the user would not have to use context menu to pick up those. And such entries would show up even if app does not have menu on its own. }

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates containers.

It is also possible to save the current application instance set of the container as a preset (e.g. KWrite and Konqueror in GAI), and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

At some point, we would like to be able to configure launching saved groups with arguments (e.g. file names), including which new application instances should get what arguments. This would allow e.g. an action on HTML documents to open the aforementioned KWrite+Konqueror group for simultaneous viewing and editing of the document(s).

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Collapsed entry in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with collapsed tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages collapsing (merging of task entries into a single top-level entry): 
[x] collapse similar windows on the task bar 
[ ] collapse similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or collapsed entry.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over collapsing.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

TAI has special options for incremental adding: 
( ) add new entry next to the current one 
(*) add new entry as the last one 

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

When the window which had focus is closed, focus is given to the next most recent window in the historic bookkeeping. A global option allows this behavior to be changed for TAI containers.

When a window in a tabbed container is closed: 
(*) Give focus to the previously-active window 
( ) Give focus to the spatially adjacent window 
[ ] Give focus to nearest sibling of the same application kind, when possible

The second option prefers the next window, but uses the previous window if the window closed was last in the spatial order.

==== Close current document ====
''Close current document'' is only partly in the scope of NWI, as it is implemented at the application level. Applications may:
* not implement close-document
* always close the document, but never close the window
* always close the window
* conditionally close the window

This last case involves NWI communication, likely by sending a 'close-window-conditional' signal to the WM. The window will be closed if the window has at least one sibling (application instance) of the same application kind. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine. (See the glossary for a more precise definition of when application instances are considered as belonging to "the same application".)

The choice of behavior, and if any configuration is available, is left to the application.

==== Quit application ====
''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-06-03T19:49:57Z

Mwoehlke: 'keep focus on same application kind' option when closing windows

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

The desktop and each container type have their own default setting whether they should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Individual containers can also be configured for regular/shared or use the container-type default.

When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

TAI has special options for incremental adding: 
( ) add new entry next to the current one 
(*) add new entry as the last one 

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

When the window which had focus is closed, focus is given to the next most recent window in the historic bookkeeping. A global option allows this behavior to be changed for TAI containers.

When a window in a tabbed container is closed: 
(*) Give focus to the previously-active window 
( ) Give focus to the spatially adjacent window 
[ ] Give focus to nearest sibling of the same application kind, when possible

The second option prefers the next window, but uses the previous window if the window closed was last in the spatial order.

==== Close current document ====
''Close current document'' is only partly in the scope of NWI, as it is implemented at the application level. Applications may:
* not implement close-document
* always close the document, but never close the window
* always close the window
* conditionally close the window

This last case involves NWI communication, likely by sending a 'close-window-conditional' signal to the WM. The window will be closed if the window has at least one sibling (application instance) of the same application kind. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine. (See the glossary for a more precise definition of when application instances are considered as belonging to "the same application".)

The choice of behavior, and if any configuration is available, is left to the application.

==== Quit application ====
''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-06-02T21:58:20Z

Mwoehlke: /* Closing documents and windows */ update based on latest discussion

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

The desktop and each container type have their own default setting whether they should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Individual containers can also be configured for regular/shared or use the container-type default.

When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

TAI has special options for incremental adding: 
( ) add new entry next to the current one 
(*) add new entry as the last one 

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

When the window which had focus is closed, focus is given to the next most recent window in the historic bookkeeping. A global option allows this behavior to be changed for TAI containers.

When a window in a tabbed container is closed: 
(*) Give focus to the previously-active window 
( ) Give focus to the spatially adjacent window

The second option prefers the next window, but uses the previous window if the window closed was last in the spatial order.

==== Close current document ====
''Close current document'' is only partly in the scope of NWI, as it is implemented at the application level. Applications may:
* not implement close-document
* always close the document, but never close the window
* always close the window
* conditionally close the window

This last case involves NWI communication, likely by sending a 'close-window-conditional' signal to the WM. The window will be closed if the window has at least one sibling (application instance) of the same application kind. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine. (See the glossary for a more precise definition of when application instances are considered as belonging to "the same application".)

The choice of behavior, and if any configuration is available, is left to the application.

==== Quit application ====
''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-06-01T16:21:47Z

Mwoehlke: root containers "can't" be closed (logging off doesn't count), so don't need to say "non-root"

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

The desktop and each container type have their own default setting whether they should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Individual containers can also be configured for regular/shared or use the container-type default.

When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine. (See the glossary for a more precise definition of when application instances are considered as belonging to "the same application".)

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 
[x] confirm closing container with multiple windows 

''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-26T21:43:23Z

Mwoehlke: another try at shared menu wording, add ref to glossary when talking about 'belonging to same application'

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

The desktop and each container type have their own default setting whether they should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Individual containers can also be configured for regular/shared or use the container-type default.

When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine. (See the glossary for a more precise definition of when application instances are considered as belonging to "the same application".)

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-26T16:57:49Z

Mwoehlke: minor edits, updates to "application" in glossary

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

Each type of container has its own setting whether it should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. User can change the default value of this settings or specify it for each individual container. When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in that container (not limited to immediate children) — "take all" mechanism.

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

Data saved:
* set of windows of the container
* container type
* container class name
* container title
* container shared menu settings

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

{ nicer screenshot to show both of them in action }

Similar windows are those belonging to the same application, or containers with the same class. By default, each container is assigned a "class name" from its initial: contents and type. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror). Also refers to the collection of all application instances which are of the same application kind running with the same access class (see below).
; application instance : See application window. For this page, an instance is '''not''' the same as a process.
; application window : A window of a particular application { usually used when discussing sibling windows where some may be the same application }. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

When considering if two application instances belong to the same application, a number of factors which together comprise the "access class" (roughly referring to the expected permission set possessed by the application instance) are considered. These are the instance's security credentials { for now, only euid is considered } and host machine. Two windows are not considered as belonging to the same application if:
* They are running from different machines (e.g. one local, one remote over X forwarding or specification of a remote X server)
* They were started under different users
* They do not belong to the same X session

It should be noted that the window manager only considers windows under its control — that is, those running in the same X session. An application instance in another session cannot be considered as another instance of an application, since the window manager would not know about such a window.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-21T17:09:15Z

Mwoehlke:

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Default options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

''Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the side effect of giving us the much-requested "virtual desktop" feature, or at least putting us very close to having it.''

=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser).

Each container may also specify if it should display a unified (shared) menu, or allow menus to be displayed in the child windows as they normally would. Each container type has its own default value for this setting that can be changed for individual containers. When displaying a shared menu, the menu for the active leaf (that is, the descendent window that has input focus) is displayed in the top of the container, and no other menus are displayed in the container (not limited to immediate children).

Default options: 
[ ] GAI uses shared menu 
[ ] FAI uses shared menu 
[ ] TAI uses shared menu 
[ ] override the container setting for the desktop 
     [ ] desktop uses shared menu 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
[x] group similar windows on the task bar 
[ ] group similar windows in pop-up lists

By default, each container is assigned a "class name" from the type of container and its contents. The class name can also be changed by the user for fine control over grouping. This name is included when saving container sets.

''A pop-up list would be e.g. the menu that appears when selecting a task bar entry for a container or group.''

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application (which may belong to more than one process).''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : See application window. For this page, an instance is ''not'' the same as a process.
; application window : A window of a particular application, usually used when discussing sibling windows where some may be the same application. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-20T21:18:01Z

Mwoehlke:

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the happy side effect of giving us the much-requested "virtual desktop" feature :-), or at least putting us very close to having it.


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the application window's container, or within the container's parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
(*) no auto-grouping 
( ) group applications only 
( ) group similar windows { it will be explained later } 
[ ] group entries in containers

By default, each container is assigned a "class name" from the type of container and its contents. Saved containers have their own class name. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most applications quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

''Quit application is not really in scope of NWI, but since it is related to closing application window(s), we list it for the purpose of reference and to show the difference between those two actions. This document does not address the question whether "quit application" should exit only the active window, the corresponding application process, or all instances of the application.''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : See application window. For this page, an instance is ''not'' the same as a process.
; application window : A window of a particular application, usually used when discussing sibling windows where some may be the same application. A process (as defined by the operating system) may have more than one application window.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-20T21:10:29Z

Mwoehlke: /* Task bar presentation */

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the happy side effect of giving us the much-requested "virtual desktop" feature :-), or at least putting us very close to having it.


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the application window's container, or within the container's parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Container presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

Containers will use a window title that may represent information about the active window and/or the container type. This can be changed by the user, per container, in a similar manner to naming tabs in Konsole. Special character sequences may be used to substitute information such as the window title of the active child, or the descendent which has input focus (or "would have", if the container is given focus). These titles are used in the container's title bar, where applicable, and in task lists (task bar, window switcher, etc.).

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
(*) no auto-grouping 
( ) group applications only 
( ) group similar windows { it will be explained later } 
[ ] group entries in containers

By default, each container is assigned a "class name" from the type of container and its contents. Saved containers have their own class name. The class name can also be changed by the user for fine control over grouping.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application instance
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most application instances quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior. For regular application (such they don't stay in systray) closing its window is equivalent with quitting the application process.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

''Application quit is not really in scope of NWI but since it is related to closing application window we put it there just as reference and to show the difference between those two actions.''

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application window : A window of a particular application process, usually used when discussing sibling windows where some may be the same application. A process may have more than one application window.
; application instance : another term for application window
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-20T18:21:24Z

Mwoehlke: /* Nested Windows Interface (NWI) */ fix typo/thinko

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the happy side effect of giving us the much-requested "virtual desktop" feature :-), or at least putting us very close to having it.


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the application window's container, or within the container's parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
(*) no auto-grouping 
( ) group applications only 
( ) group similar windows { it will be explained later } 
[ ] group entries in containers

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application instance
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most application instances quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior. For regular application (such they don't stay in systray) closing its window is equivalent with quitting the application instance.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-20T18:09:11Z

Mwoehlke: /* Floating Application Interface (FAI) */

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options: 
[ ] Show scrollbars (when needed) and allow windows to be moved outside the visible area. 
(*) Use mini-task-bar 
( ) Minimize windows to bottom of window (appear as shaded title bars) 
( ) Minimize windows in place (minimize == shade) 

Writing the FAI backend to allow scroll bars, and rewriting the root as another FAI container, should have the happy side effect of giving us the much-requested "virtual desktop" feature :-), or at least putting us very close to having it.


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the parent container, or within the parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
(*) no auto-grouping 
( ) group applications only 
( ) group similar windows { it will be explained later } 
[ ] group entries in containers

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application instance
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most application instances quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior. For regular application (such they don't stay in systray) closing its window is equivalent with quitting the application instance.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-20T16:11:39Z

Mwoehlke: minor wording improvements and proofing

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type. When using multiple desktops, each desktop is considered a separate container; as such, individual desktops may be set to different container types (e.g. desktop 1 is TAI, desktop 2 is GAI, desktops 3 and 4 are FAI).

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the parent container, or within the parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the task bar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

NWI also provides options for controlling the way the task bar manages grouping (merging of task entries into a single top-level entry): 
(*) no auto-grouping 
( ) group applications only 
( ) group similar windows { it will be explained later } 
[ ] group entries in containers

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it. Once a container is created, the user can label it as she/he likes (the label will be used as the container title, e.g. in the titlebar, task bar, switcher, etc.).

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty application windows (that is, application windows with no document opened) are allowed.

* close current document
* quit current application instance
* close current application window/tab
* close current application window/tab siblings (i.e. close all children of the parent, except the current one)
* close parent container of the current application window/tab (not counting desktop)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most application instances quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior. For regular application (such they don't stay in systray) closing its window is equivalent with quitting the application instance.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| quit current application instance || [ctrl+q]
|-
| close current application window/tab || <none> { alt+q? }
|-
| close current application window/tab siblings || <none>
|-
| close parent container of the current application window/tab || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-19T20:04:12Z

Mwoehlke: more assorted edits

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of an application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type.

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the parent container, or within the parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instance set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the taskbar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded windows is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add a new application instance of the same type as the current window, as a new sibling of the current window (equivalent to the "new tab" feature of many web browsers)
* add a duplicate of the current application instance (i.e. it "copies" the application instance and the document)
* add the "hollow" application — after that you drag&drop the desired window, or start a new application instance; it will be "sucked" into the container
* drag&drop a window directly to the container without creating the hollow application

There can be only one hollow application instance for the entire session (all desktops). If the user tries to create a new hollow application instance, the previous one disappears. Existence of the hollow application instance indicates that the next user action will be adding a window to that container (thus drag&drop is easier in such case). Note that dialogs are not "sucked in" (this would be inconvenient if the dialog is the application launcher!).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are distinct actions. The WM provides an option to control that behavior: 
[x] allow tearing off window while rearranging

If this option is turned off, then a window cannot "fall off" the container while being moved.

=== Closing documents and windows ===

Empty containers (except for desktop) are not allowed; empty applications (that is, application windows with no document opened) are allowed.

* close current document
* close current window
* close current window siblings (i.e. close all children of the parent, except the current one)
* close topmost container (not counting desktop)

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Closing an entire container means that all windows within the container are closed. Most application instances quit when their windows are closed. Some kinds of application may continue to run after their windows are closed (systray applications, in particular, whose systray icons remain after their windows are closed). The use of containers does not change this behavior.

Default options for user actions: 
[ ] on close of document, close "its" application instance as well if there are sibling instances of such application kind within the container 
[x] on close of last application instance in container, keep this instance (do not close it) 
    [x] close the document only instead 

=== Container special menu items ===

* Accept new application ''(add hollow application)''
* Convert to...
** GAI
** FAI
** TAI
* Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| close current application || [ctrl+q]
|-
| close current application siblings || <none>
|-
| close current window || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging windows. The user can exchange the marked window with any other one (not only siblings). After exchange, the marked window remains marked (exchange is not switch). Exchange means that windows take each other's "places" in a geometrical sense (which includes position in the container hierarchy).

Initially, the current application instance is marked.

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-19T18:10:25Z

Mwoehlke: /* Arranging windows as container */

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type.

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the parent container, or within the parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instances set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the taskbar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded application instances is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "create container" (control dialog appears with "accept" and "cancel" buttons and container type selection)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add the application instance as current one
* add the duplicate of the current application instance (i.e. it "copies" application instance and the document)
* add "hollow" application — after that you drag&drop desired application instance or start new, it will be "sucked" into the container
* drag&drop application instance directly to the container without creating hollow application

There can be only one hollow application instance per entire KDE (all desktops). If user tries to create new hollow application instance, the previous one disappears. Existence of hollow application instance indicates that the next user action will be adding application instance to that container (thus drag&drop is easier in such case).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are technically two distinct actions. WM provides option to control that behaviour: 
[x] allow tearing off window while rearranging

If this option is turned off while moving the window of application instance (in FAI for example), the window cannot "fall off" the container.

=== Closing documents, application instances and windows ===

Empty containers (except for desktop) are not allowed; empty applications (that is, application windows with no document opened) are allowed.

* close current document
* close current application
* close current window { container }
* close current window { application } siblings (i.e. close all children of the parent, except the current one)
* close topmost container (not counting desktop)

An "application" here refers to all windows belonging to a particular kind of program (e.g. "kwrite", "konqueror"), including those belonging to different processes, so closing an application should result in no instances of that application running (at least within a given user/session).

{ see ML for sorting this out }

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Default options for "close current document": 
[ ] closing document closes "its" application if there are sibling instances of that application within the container 
[x] do not allow closing last application instance in container 
    [x] instead of closing last application instance in container, close the document only 

Closing an entire container means all application instances close their windows — for regular applications it means they quit, but for systray applications it means the windows are closed but the application instances keep running (indicating that fact by showing appropriate icons in the systray).

=== Container special menu items ===

{| class="wikitable" cellpadding=6 cellspacing=2
| Accept new application ''(add hollow application)''
|-
| Convert to...
|-
|      GAI
|-
|      FAI
|-
|      TAI
|-
| Save set as...
|}

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| close current application || [ctrl+q]
|-
| close current application siblings || <none>
|-
| close current window || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging application instances. The user can exchange the current application instance with any other one (not only siblings). After exchange, the current application instance still has focus (exchange is not switch). Exchange means application instances take each other "places" in a geometrical sense (which includes position in the container hierarchy).

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window of application instance to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-19T18:06:07Z

Mwoehlke: reword shared menus section, also add that decorations can change visual of containers

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type.

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

The visual aspect of containers is controlled by the window decorator, so different decorators may make different choices regarding how containers are displayed (for example, TAI might have a title bar and tab strip, or might combine the two in the manner of Google's Chrome browser). It is recommended that decorations provide menu placement as an option, per container type. This will control if the menu appears within the application instance window (which would mean many menus in FAI, GAI containers), within the parent container, or within the parent container. The last choice cascades; that is, the menu is "pushed" up until a container that does not use this option (the root cannot, as it has no parent). With all containers displaying in the parent, menus would appear as in OS-X; that is, one menu bar at the top of the screen, which changes to reflect the window that has focus.

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instances set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the taskbar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded application instances is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "select windows" (control dialog appears with "accept" and "cancel" buttons)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add the application instance as current one
* add the duplicate of the current application instance (i.e. it "copies" application instance and the document)
* add "hollow" application — after that you drag&drop desired application instance or start new, it will be "sucked" into the container
* drag&drop application instance directly to the container without creating hollow application

There can be only one hollow application instance per entire KDE (all desktops). If user tries to create new hollow application instance, the previous one disappears. Existence of hollow application instance indicates that the next user action will be adding application instance to that container (thus drag&drop is easier in such case).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are technically two distinct actions. WM provides option to control that behaviour: 
[x] allow tearing off window while rearranging

If this option is turned off while moving the window of application instance (in FAI for example), the window cannot "fall off" the container.

=== Closing documents, application instances and windows ===

Empty containers (except for desktop) are not allowed; empty applications (that is, application windows with no document opened) are allowed.

* close current document
* close current application
* close current window { container }
* close current window { application } siblings (i.e. close all children of the parent, except the current one)
* close topmost container (not counting desktop)

An "application" here refers to all windows belonging to a particular kind of program (e.g. "kwrite", "konqueror"), including those belonging to different processes, so closing an application should result in no instances of that application running (at least within a given user/session).

{ see ML for sorting this out }

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Default options for "close current document": 
[ ] closing document closes "its" application if there are sibling instances of that application within the container 
[x] do not allow closing last application instance in container 
    [x] instead of closing last application instance in container, close the document only 

Closing an entire container means all application instances close their windows — for regular applications it means they quit, but for systray applications it means the windows are closed but the application instances keep running (indicating that fact by showing appropriate icons in the systray).

=== Container special menu items ===

{| class="wikitable" cellpadding=6 cellspacing=2
| Accept new application ''(add hollow application)''
|-
| Convert to...
|-
|      GAI
|-
|      FAI
|-
|      TAI
|-
| Save set as...
|}

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| close current application || [ctrl+q]
|-
| close current application siblings || <none>
|-
| close current window || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging application instances. The user can exchange the current application instance with any other one (not only siblings). After exchange, the current application instance still has focus (exchange is not switch). Exchange means application instances take each other "places" in a geometrical sense (which includes position in the container hierarchy).

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window of application instance to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-19T17:57:29Z

Mwoehlke: update glossary (and remove ?AI acronyms; not needed as they have their own sections)

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an window of application instance with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type.

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application instance, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several application instances in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

[[File:Mac-shared-menu.png|240px|thumb|right|Mac shared menu]]

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

You can configure each container type (+ desktop separately) to show shared menu per whole container — menu of the pane of the active application instance. Shared menu goes "up" as it can (as far container accepts shared menu). It is similar to Mac menu concept but not limited to desktop.

Shared menu — default settings: 
[ ] desktop 
[ ] GAI 
[ ] FAI 
[x] TAI 

== Features ==

Containers cannot get focus — only the windows of application instances within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the application instances, but also recreates grouping.

It is also possible to save the current application instances set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the taskbar]]

The task bar shows (directly) only those windows that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded application instances is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "select windows" (control dialog appears with "accept" and "cancel" buttons)
# select desired windows
# click LMB on "accept" or press [Enter] key — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add the application instance as current one
* add the duplicate of the current application instance (i.e. it "copies" application instance and the document)
* add "hollow" application — after that you drag&drop desired application instance or start new, it will be "sucked" into the container
* drag&drop application instance directly to the container without creating hollow application

There can be only one hollow application instance per entire KDE (all desktops). If user tries to create new hollow application instance, the previous one disappears. Existence of hollow application instance indicates that the next user action will be adding application instance to that container (thus drag&drop is easier in such case).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are technically two distinct actions. WM provides option to control that behaviour: 
[x] allow tearing off window while rearranging

If this option is turned off while moving the window of application instance (in FAI for example), the window cannot "fall off" the container.

=== Closing documents, application instances and windows ===

Empty containers (except for desktop) are not allowed; empty applications (that is, application windows with no document opened) are allowed.

* close current document
* close current application
* close current window { container }
* close current window { application } siblings (i.e. close all children of the parent, except the current one)
* close topmost container (not counting desktop)

An "application" here refers to all windows belonging to a particular kind of program (e.g. "kwrite", "konqueror"), including those belonging to different processes, so closing an application should result in no instances of that application running (at least within a given user/session).

{ see ML for sorting this out }

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Default options for "close current document": 
[ ] closing document closes "its" application if there are sibling instances of that application within the container 
[x] do not allow closing last application instance in container 
    [x] instead of closing last application instance in container, close the document only 

Closing an entire container means all application instances close their windows — for regular applications it means they quit, but for systray applications it means the windows are closed but the application instances keep running (indicating that fact by showing appropriate icons in the systray).

=== Container special menu items ===

{| class="wikitable" cellpadding=6 cellspacing=2
| Accept new application ''(add hollow application)''
|-
| Convert to...
|-
|      GAI
|-
|      FAI
|-
|      TAI
|-
| Save set as...
|}

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| close current application || [ctrl+q]
|-
| close current application siblings || <none>
|-
| close current window || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application instance to application instance. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift] — default mod key will likely be [alt] or [win].

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging application instances. The user can exchange the current application instance with any other one (not only siblings). After exchange, the current application instance still has focus (exchange is not switch). Exchange means application instances take each other "places" in a geometrical sense (which includes position in the container hierarchy).

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — the window of application instance to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Glossary ==

; application : An application kind in general sense (e.g. Konqueror) running on a unique machine. Two instances of the same application kind, but running on different machines (e.g. one local instance, one instance being run over X forwarding) are considered different applications.
; application instance : A window of a particular application kind, usually used when discussing sibling windows where some may be the same application. A process may have more than one application instance.
; container : A special type of window which is not an application instance, but contains one or more child windows.
; leaf : An application instance or other window which is not a container; may also include dialogs, etc.
; root : The node in the window tree corresponding to the desktop. The root has no parent, and its siblings are the other virtual desktops.
; sibling : A window belonging to the same direct parent container as a reference window.
; window : An object (area) in sense of the geometry which is either an application instance or a container.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-16T02:03:59Z

Mwoehlke: /* Closing documents, applications and windows */

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) on [https://mail.kde.org/mailman/listinfo/kde-usability kde-usability] (and later [https://mail.kde.org/mailman/listinfo/kde-usability-devel kde-usability-devel]) mailing list — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

[[File:Nwi-rationale.png|240px|thumb|right|Kpdf + manual "grouping" of KWrite and Konqueror]]

NWI is thought as a uniform UI on one hand, while helping to increase productivity by extending the idea of tiles and tabs on the other. Consider an example: you edit some data in one application (e.g. an html file in KWrite), and you view the results using another application (in this instance, Konqueror). So although there is no relation between KWrite and Konqueror, for this task — a task you perform right now — those two applications are related. Currently — if you run more than those two applications — when you switch to KWrite, the Window Manager (WM) will bring only KWrite to the front. If another window has meanwhile covered Konqueror, you now have to bring that window to the front by yourself. This is tiresome. With grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

NWI moves document grouping from the application level to the Window Manager level. Multiple applications — even those using unrelated toolkits (e.g. KDE and Gnome) — can be grouped and managed as a single entity. You are probably familiar with tabs from modern web browsers, and split views from e.g. Kate. Now imagine every program you use having tab support, split view support, and being able to combine them in any combination.

== What is it? ==

Probably you are already familiar with several User Interface designs; TDI, MDI, SDI, and so on. Some of them have proven to be very useful, some of them, not especially. In the NWI world, the most basic — yet the more flexible — UI you can think of is built from those below:

=== Single Application Interface (SAI) ===

[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]

This is really the simplest UI; no magic here. All you have is just an application window with some data — if a "window" can hold only one document, it is SAI. Examples: Kpdf, Okular.

Applications can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to: 
off → start as SAI, user can add another tab later 
on → from the start work as TAI (show even single tab)

In another sense, SAI can be thought of as a leaf; an actual window, rather than one of the container types that follow.

=== Grouped Applications Interface (GAI) ===

''A more accurate name would be Tiling Applications Interface, but this would produce the same acronym as Tabbed Applications Interface.''

GAI is a container that displays multiple "views" (a window, document, or other collection of data or controls) next to each other, vertically and/or horizontally, usually with no space between. From a geometrical point of view, GAI container behaves as one window with many panes. Example: Kate, KMail.

GAI has one shared titlebar (for the container), plus at user request each embedded window may have a mini-titlebar.

When you finish grouping, you still can change the proportions of the group "panes". You can also rearrange them — via context menu or simply like dragging docked windows. Changing the size of one pane will generally change the size of adjacent panes, so that the entire container is filled.

=== Floating Application Interface (FAI) ===

The most common FAI container is desktop; windows in an FAI container can be moved freely, and altering the geometry of one window does not have an effect on any others. While the desktop will default to FAI mode, it is possible to switch it to another type.

The FAI container can be any non-root container as well — being able to convert to/from any container, FAI helps reorganizing windows inside GAI. Non-root FAI is what some people (especially those familiar with its use in the Microsoft world) call "MDI".

A minimized window in an FAI root container (desktop) is hidden and accessible from the task bar/panel. Windows in a non-root FAI container "minimize" to just a title bar (much like shading), so they are directly accessible all the time.

When resizing the parent container, the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If this is no longer possible, the windows are resized.

Possible options:
* Show scrollbars (when needed) and allow windows to be moved outside the visible area. This is arguably the much-requested "virtual desktop" feature if applied to the root container.
* Have a mini-panel in FAI containers? (Is it possible to integrate with plasma for this?)
* "Minimized" windows' title bars are moved to the bottom of the container?


=== Tabbed Applications Interface (TAI) ===

If you've used a modern web browser, you have almost certainly experienced TAI in the form of TDI (Tabbed Document Interface). You launch one application, and you can then open multiple data views (documents, web pages, even shell sessions) in one window, with one per tab. Example: Konqueror, Konsole.

TAI goes a little further than TDI, because you can arrange several applications in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file. (Microsoft Internet Explorer does this to a limited extent with Adobe Acrobat integration. Imagine being able to open any document from a web page in an appropriate viewer and have it be just another tab.)

By default, tabs are shown at the top of the window, but the user can choose for them to be on any side. This can be configured both as a global default, and per container.

=== Nested Windows Interface (NWI) ===

Once the container is arranged, you can think of it as a window. As such, you can put into another container, thus nesting containers. Therefore, the UI in general is called NWI; Nested Windows Interface.

You can configure each container type (+ desktop separately) to show shared menu per whole container — menu of the active application pane. Shared menu goes "up" as it can (as far container accepts shared menu).

Shared menu — default settings: 
[ ] desktop 
[ ] GAI 
[ ] FAI 
[x] TAI 

== Features ==

Containers cannot get focus — only the applications within can get focus — however they appear in window lists (e.g. window switcher, task bar) as if they could get the focus (you can think of the container as focus-proxy). Requesting that a container be given focus (e.g. by window switcher, task bar, or clicking the container's title bar) will give focus to the window within that container that most recently had focus. If that window is itself a container, then the window in ''that'' container that most recently had focus will receive it, and so on until a leaf (a non-container window) is reached.

=== Session management ===

When you turn the session management on (at KDE level), SM not only restores the applications, but also recreates grouping.

It is also possible to save the current application set of the container as a preset (like: Kwrite+Konqueror) and then later launch such group at once. This saves recreating commonly-used groups.

=== Task bar presentation ===

[[File:Taskbar_list.png|240px|thumb|right|Group list in the taskbar]]

The task bar shows (directly) only those windows — be they leaves or containers — that live directly in the root container. When user clicks LMB on
container entry in the task bar, the list of all embedded applications is shown (containers show items which expand to the windows they contain, and so on). As with grouped tasks, containers show a small number with the number of windows they contain.

=== Managing the containers ===

Except for the root container (the desktop), empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

==== Arranging windows as container ====

# launch applications as you like
# RMB on the desktop to get context menu
# choose "select windows"
# select desired windows
# RMB on the desktop to get context menu again
# choose "group selection" — container is created

To select windows:
* with Shift+LMB pressed down select region over the windows (like in KSnapshot)
* with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting; this is useful for FAI containers.

==== Incremental adding ====

[[File:Gai-adding_app.png|240px|thumb|right|Creating GAI by adding hollow application]]

You can:
* add the application as current one
* add the duplicate of the current application (i.e. it "copies" application and the document)
* add "hollow" application — after that you drag&drop desired application or start new, it will be "sucked" into the container
* drag&drop application directly to the container without creating hollow application

There can be only one hollow application per entire KDE (all desktops). If user tries to create new hollow application, the previous one disappears. Existence of hollow application indicates that the next user action will be adding application to that container (thus drag&drop is easier in such case).

==== Disassembling the container ====

* user can convert any container to any other type (for example FAI to GAI)
* user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

From the accepting container's point of view, tearing off is the same as adding a window.

Please note that moving embedded windows within a container and tearing them off are two distinct actions; i.e. while moving the application (in FAI for example), the application cannot "fall off" the container.

=== Closing documents, applications and windows ===

Empty containers (except for desktop) are not allowed; empty applications (that is, application windows with no document opened) are allowed.

* close current document
* close current application
* close current window
* close current window siblings (i.e. close all children of the parent, except the current one)
* close topmost container (not counting desktop)

An "application" here refers to all windows belonging to a particular kind of program (e.g. "kwrite", "konqueror"), including those belonging to different processes, so closing an application should result in no instances of that application running (at least within a given user/session).

Depending on user preference, closing the current document may be denied, may give an "empty application", or may close the current window. When making this decision, "application instances" need not belong to the same process, although they do need to be running on the same machine.

Default options for "close current document": 
[ ] closing document closes "its" application if there are sibling instances of that application within the container 
[x] do not allow closing last application instance in container 
    [x] instead of closing last application instance in container, close the document only 

Closing a entire container means each application quits, not just closes its "pane". This difference is important for systray applications — in other words, such applications are not torn off when their parent-container closes.

=== Special container menu items ===

Accept new application ''(add hollow application)'' 
Convert to...
* GAI
* FAI
* TAI
Save set as...

=== Default key bindings ===

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Closing
|-
| close current document || [ctrl+w]
|-
| close current application || [ctrl+q]
|-
| close current application siblings || <none>
|-
| close current window || [alt+f4]
|-
| close topmost container || [alt+shift+f4]
|-
! colspan=2 | Changing container type
|-
| to GAI || <none>
|-
|to FAI || <none>
|-
|to TAI || <none>
|-
! colspan=2 | Adding applications
|-
| empty copy || [ctrl+n]
|-
| duplicate || [ctrl+d]
|-
| hollow || [ctrl+h]
|-
| start direct dragging || [ctrl+LMB]
|-
|}

== Switchers ==

A switcher is a program that lets the user switch from application to application. Visual appearance is up to the switcher. The user will select one switcher to be the primary switcher; other switchers may be configured as "auxiliary switchers", with any number of auxiliary switchers possible at one time.

The primary switcher is activated by pressing and holding a "mod" key plus another key to make a navigation key. (For example, a navigation key might be [tab] or [shift-tab]; using mod as [alt] gives the switching keys commonly known today.) At that point, the primary switcher is active, and to keep it running, the user must continue to hold the mod key. Releasing the mod key will give focus to the window currently in the switcher; pressing the cancel key (default [escape]) will cancel the switch. Switchers may also (optionally) make use of the mouse.

Auxiliary switchers are triggered by a global key or key combination. The combination need not include a modifier, and it is not needed to hold a modifier to keep the switcher active. The switcher will be operational until the user commits the switch (default [enter]) or cancels the switch.

Mod is any modifier key allowed/recognized by X, except [ctrl] and [shift].
{ Default mod key will likely be [alt] or [win]; any mod key is allowed — but it seems limited, why [meta] couldn't be mod key? }

When window is a container, after switching to it, focus is given as described at the top of the Features section. Each container remembers the last window to have focus.

==== Exchange ====

Switchers are used for switching (focus change) windows, but they have another purpose: exchanging applications. The user can exchange the current application with any other one (not only siblings). After exchange, the current application still has focus (exchange is not switch). Exchange means applications take each other "places" in a geometrical sense (which includes position in the container hierarchy).

=== Keyboard shortcut actions ===

* (window, desktop) sequence switch
* (window, desktop, global) historic switch
* (window, desktop) spatial switch
* (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on the current desktop, marked "window" are constrained to the parent container of the active window.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:
* sequence — direct children only
* historic — direct children only
* spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:
* GAI — historic
* FAI — historic
* TAI — spatial

User can choose (option) if she/he prefers switch-wrap on or off, for each switcher mode separately. For sequence and historic switching, wrap means after last comes the first (and vice versa); for spatial that after rightmost comes the leftmost, after lowest comes the highest (and vice versa).

Default settings: 
[x] sequence wrap 
[x] historic wrap 
[ ] spatial wrap 

==== Spatial and sequence switching properties ====

Both of these switching modes are based on window placement, so for TAI container they are equivalent.

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order"). Thus you can call sequence switching as switch-as-you-read (titlebars). It means that container edges are no limits for sequence switch, but they are limits for spatial switch.

Another observation — an application to the right of its neighbor is not always left for spatial switch; that is, spatial-switch-left followed by spatial-switch-right may not put you back where you started. For sequence switch there is such guarantee: when you switch next and then previous, you will always return to the same place.

=== Default keyboard bindings ===

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

{| class="wikitable" cellpadding=6 cellspacing=2
! colspan=2 | Sequence switch
|-
| window previous || [win+backspace]
|-
| window next || [win+shift+backspace]
|-
| desktop previous || [alt+backspace]
|-
| desktop next || [alt+shift+backspace]
|-
! colspan=2 | Spatial switch
|-
| window up || [win+up]
|-
| window down || [win+down]
|-
| window right || [win+right]
|-
| window left || [win+left]
|-
| desktop up || [alt+up]
|-
| desktop down || [alt+down]
|-
| desktop right || [alt+right]
|-
| desktop left || [alt+left]
|-
! colspan=2 | Historic switch
|-
| window back || [win+pgup]
|-
| window forward || [win+pgdn]
|-
| desktop back || [alt+pgup]
|-
| desktop forward || [alt+pgdn]
|-
| global back || [alt+ctrl+pgup]
|-
| global forward || [alt+ctrl+pgdn]
|-
! colspan=2 | Smart switch
|-
| window previous || [win+shift+tab]
|-
| window next || [win+tab]
|-
| desktop previous || [alt+shift+tab]
|-
| desktop next || [alt+tab]
|-
! colspan=2 | Other actions
|-
| cancel switch || [mod+escape]
|-
| commit switch || [mod+enter] (or just release [mod])
|-
| exchange || [mod+ins]
|}

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.

== Links ==

References:
* [http://en.gentoo-wiki.com/wiki/Window_Managers Gentoo Window Managers]
* [http://modeemi.fi/~tuomov/ion/ Ion], (successor of PWM) tiling and tabbing Window Manager

Projects:
* [http://developer.kde.org/seasonofkde/project.php?kwin_tabs.xml Season of KDE 2006], tabs (window groups) support in KWin
* [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022561044 GSoC 2009], Show Student Project KWin: Window tabbing for KDE

Bounties:
* [http://www.undefinedfire.com/kde/500-kwin-bounty/ TAI Bounty], $500 bounty for adding TAI to KWin

KDE wish reports:
* [https://bugs.kde.org/show_bug.cgi?id=42023 PWM-like tabbing support for windows], adding TAI to KWin
* [https://bugs.kde.org/show_bug.cgi?id=120595 Enable grouping of windows by welding the edges together], same as GAI concept but container window does not have to be rectangular,
* [https://bugs.kde.org/show_bug.cgi?id=59338 Window tiling (Ion-like window layout and control)], desktop as GAI container,

Projects/Usability/NWI

2009-05-16T01:21:16Z

Mwoehlke: assorted additions and proofing

Schedules/KDE4/4.3 Feature Plan

2009-04-06T23:53:43Z

Mwoehlke: /* kdegames */

This is a list of planned features for the 4.3 release.

See also:
* [[Schedules/KDE4/4.3 Release Schedule]]
* [[Schedules/KDE4/4.3 Release Goals]]
* [[Schedules/KDE4/4.2 Feature Plan]]

Legend:
* todo => not started yet
* in-progress => started, but not completed yet
* done => completed
__TOC__

= Other =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Akonadi|Various Akonadi related items can be found here http://techbase.kde.org/Projects/PIM/Akonadi#Scheduled_for_KDE_4.3_.2F_Akonadi_1.2|kde-pim@kde.org|Akonadi Developers}}
{{FeatureInProgress|KPackageKit|Pushing in KPackageKit (dependant on PolicyKit integration)|dantti85-dev@yahoo.com.br|Daniel}}
|}

= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KLocale|Investigate adding Currency Code and currency minor units support based on ISO 4217 (http://en.wikipedia.org/wiki/ISO_4217).|john@layt.net|John Layt}}
{{FeatureDone|kdecore|Thread safety in ksycoca (KService, KMimeType etc.)|faure:AT:kde.org|David Faure}}
{{FeatureTodo|kdecore|Dynamic allocation of KDebug areas|faure:AT:kde.org|David Faure}}
{{FeatureInProgress|Sonnet|Implement language detection|qbast@go2.pl|Jakub Stachowski}}
{{FeatureInProgress|Sonnet|Integrate language detection with spellchecking|qbast@go2.pl|Jakub Stachowski}}
{{FeatureTodo|Sonnet|Integrate language detection with strigi|qbast@go2.pl|Jakub Stachowski}}
{{FeatureTodo|Sonnet|Grammar checking (at least for English)|qbast@go2.pl|Jakub Stachowski}}
{{FeatureInProgress|kio|Move KTcpSocket to kio and make it public; some cleanup required|ahartmetz@gmail.com|Andreas Hartmetz}}
{{FeatureTodo|KCalendarSystem|Add new astronomical calculation support classes to be used in kdelibs to build new astronomically based calendar systems, and in kdepim to build new version of libkholiday.|john@layt.net|John Layt}}
{{FeatureTodo|KCalendarSystem|Add new calendar systems: Indian Civil (Saka), Ethiopean, Chinese, Pure Julian, Pure Gregorian, etc.|john@layt.net|John Layt}}
{{FeatureTodo|KDEPrint|If no file printing support in Qt4.5, migrate FilePrinter class from Okular to enable file printing for all apps via QPrinter. To be discussed on k-c-d first.|john@layt.net|John Layt}}
{{FeatureTodo|KDEPrint|Add framework for standard actions for 'Send to...' for e-mail, fax, etc by printing to PDF/PS.|john@layt.net|John Layt}}
{{FeatureTodo|kdeui|entries to help menu and aboutdata pointing to UserBase entry and forum.kde.org|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|kdesu|Classes to help kde-apps open ports in the local firewall (via IPTables/IPFW, etc...)|tejas@gja.in|Tejas Dinkar}}
{{FeatureInProgress|katepart|Key mapping support for the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}
{{FeatureInProgress|katepart|Blockwise visual mode for the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}
{{FeatureInProgress|katepart|Improve text objects in the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}
{{FeatureTodo|katepart|Save registers and marks from the vi input mode|ehamberg-hjå-gmail.com|Erlend Hamberg}}
{{FeatureInProgress|kio|Fix D-Bus timeout in SlaveBase when calling kpasswdserver|lemma@confuego.org|Michael Leupold}}
{{FeatureInProgress|kdeui|Provide a class for detecting modifier keystrokes and locked key states|lemma@confuego.org|Michael Leupold}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Non-Plasma, Non-KWin
{{FeatureTodo|Kxkb|Support for languages in keyboard layout descriptions|rysin:AT:kde.org|Andriy Rysin}}
{{FeatureDone|PolicyKit integration|Import PolicyKit-KDE from extragear|drf54321@gmail.com|Dario Freddi}}
{{FeatureDone|Solid Actions KCM|Import Solid actions KControl module from playground|ben@eclipse.endoftheinternet.org|Ben Cooksley}}
{{FeatureTodo|KControl4|Import refactor of systemsettings with Tree and Icon view support|ben(at)eclipse(dot)endoftheinternet(dot)org+msoeken(at)informatik(dot)uni-bremen(dot)de|Ben Cooksley and Mathias Soeken}}
{{FeatureDone|KSysguard|Added GetHotNewStuff support|a@b.com|name}}
{{FeatureInProgress|KActiveEdges|Split active screen edges from KWin|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureInProgress|Solid Wicd Engine|Import Solid Wicd engine from github/playground|drf54321@gmail.com|Dario Freddi}}
{{FeatureDone|Klipper|Made klipper automatically find possible actions based on filename copied to clipboard|dimsuz@gmail.com|Dmitry Suzdalev}}
{{FeatureDone|Klipper|Improved action adding/editing workflow by implementing a special dialog for editing a certain action|dimsuz@gmail.com|Dmitry Suzdalev}}
{{FeatureTodo|Klipper|Make action popup unobtrusive by showing menu only when user clicks an icon in systray. Icon itself should change to indicate availability of some actions on current clipboard|dimsuz@gmail.com|Dmitry Suzdalev}}
{{FeatureTodo|Font Installer KCM |Use PolicyKit for installtion of system-wide fonts.|craig@kde.org|Craig Drummond}}
{{FeatureInProgress|Font Settings KCM|Improved GUI for configuring anti-aliasing settings|fredrik@kde.org|Fredrik Höglund}}

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KRunner

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Plasma - Priority Features

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |Plasma
{{FeatureTodo|Now Playing data engine|Support for MPD|kde:AT:randomguy3.me.uk|Alex Merry}}
{{FeatureDone|Classic Menu Launcher|Optional recently used applications and System Settings menu|mail:AT:dipe.org|Sebastian Sauer}}
{{FeatureDone|Classic Menu Launcher|KDE3-like menu titles|mail:AT:dipe.org|Christian Loose}}
{{FeatureDone|Classic Menu Launcher|Context menu for menu items|mail:AT:dipe.org|Christian Loose}}
{{FeatureInProgress|Reusable video widget|A widget in libplasma that can play video and audio|notmart@gmail.com|Marco Martin}}
{{FeatureInProgress|Message box|A message box shown as an overlay over plasmoids|notmart@gmail.com|Marco Martin}}
{{FeatureInProgress|Systemtray protocol|New systemtray protocol beginnings: daemon and systemtray widget part|notmart@gmail.com|Marco Martin}}
{{FeatureInProgress|Default theme|Air: new default Plasma theme|notmart@gmail.com|Marco Martin and Nuno Pinheiro}}
{{FeatureInProgress|screensaver|security constraints|chanika@gmail.com|Chani}}
{{FeatureInProgress|keyboard shortcuts|configuration|chanika@gmail.com|Chani}}
{{FeatureTodo|icon plasmoid|make it suck less|chanika@gmail.com|Chani}}
{{FeatureTodo|desktop|make a plasmoid when I paste stuff|chanika@gmail.com|Chani}}
{{FeatureInProgress|extenders|Add grouping support to extenders|r.scheepmaker@student.utwente.nl|Rob Scheepmaker}}
{{FeatureInProgress|systemtray|Group multiple jobs and notifications|r.scheepmaker@student.utwente.nl|Rob Scheepmaker}}
{{FeatureInProgress|Kickoff|Add multiple columns support to Kickoff|talvik@gmail.com|Luiz Felipe Talvik}}
{{FeatureDone|folderview|Show tooltips with large previews and file metadata when hovering icons|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|folderview|Show a popup view with the folder contents when hovering a folder in the icon view|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|folderview|Add menu items to the context menu for showing the applet browser, adding panels, locking the screen, logging out etc.|fredrik@kde.org|Fredrik Höglund}}
{{FeatureInProgress|folderview|Add menu items to the drop menu for creating applets and setting the wallpaper|fredrik@kde.org|Fredrik Höglund}}
{{FeatureTodo|folderview|Accessing sub folders as sub menus in the popup view when the applet is on the panel|fredrik@kde.org|Fredrik Höglund}}
{{FeatureTodo|folderview|Optionally show the window list menu when middle clicking the containment|fredrik@kde.org|Fredrik Höglund}}
{{FeatureTodo|folderview|Offer to create applets based on the mimetype when pasting URL's in the containment|fredrik@kde.org|Fredrik Höglund}}
{{FeatureInProgress|folderview|Implement support for keyboard navigation|jhahoneyk@gmail.com|Shantanu Tushar Jha}}
{{FeatureTodo|virus wallpaper|Move from playground to kdeplasma-addons and port to the new plasma::wallpaper|asraniel@fryx.ch|Beat Wolf}}
{{FeatureInProgress|Plasma|Add press-down feedback to folderview|haraldhv@stud.ntnu.no|Harald Hvaal}}

|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KWin - Core
{{FeatureTodo|KWin|Redesign KWin system settings GUI|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureTodo|KWin|ARGB support for decorations|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureInProgress|KWin|Window docking/quick tiling|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureTodo|KWin|Internal desktop layout/pager support|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureInProgress|KWin|Non-composited Present Windows|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureInProgress|KWin|Tabbox improvements|kde@martin-graesslin.com|Martin Gräßlin}}
|- border="1" cellpadding="5" cellspacing="0" style="border
! colspan="4" style="text-align: center" |KWin - Desktop Effects
{{FeatureTodo|KWin|Expand present windows into other effects (E.g. Desktop Grid)|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureTodo|KWin|OpenGL 3 compatible Shaders|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureTodo|KWin|Improved cube reflection|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureInProgress|KWin|Add and remove desktops in grid effect|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureTodo|KWin|Desktop Thumnails in Pager Tooltips|kde@martin-graesslin.com|Martin Gräßlin}}
{{FeatureTodo|KWin|Slide In/Out effect|hein@kde.org|Eike Hein}}
{{FeatureDone|KWin|Fade desktop effect (Desktop switcher)|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureInProgress|KWin|Highlight window effect|lmurray@undefinedfire.com|Lucas Murray}}
{{FeatureInProgress|KWin|SlideBack effect|michael_zanetti@gmx.net|Michael Zanetti}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Buildsystem|Require OpenLDAP (coordinate with the Windows team)|winter@kde.org|Allen Winter}}
{{FeatureTodo|Buildsystem|Require Cyrus-SASL (coordinate with the Windows team)|winter@kde.org|Allen Winter}}
{{FeatureTodo|libkleopatraclient|New interface library for kleopatra uiserver clients|marc@kdab.net|Marc Mutz}}
{{FeatureTodo|pimtextedit|New library around text edits, to provide support for inline images in the signature editor, among others|mcguire@kde.org|Thomas McGuire}}
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Kopete|UPnp Support|mattr@kde.org|Matt Rogers}}
{{FeatureDone|Kopete|Updated contact list interface (uses Qt 4 rather than Qt 3)|mattr@kde.org|Matt Rogers}}
{{FeatureTodo|Kopete|Update Kopete to better support Decibel|kopete-devel@kde.org|Kopete Developers}}
{{FeatureTodo|Kopete|Jabber Jingle video support|detlev.casanova@gmail.com|Detlev Casanova}}
{{FeatureTodo|Kopete|Jabber Jingle ICE support|detlev.casanova@gmail.com|Detlev Casanova}}
{{FeatureInProgress|Kopete|Contacts plasmoid|earthwings@gentoo.org|Dennis Nienhüser}}
{{FeatureTodo|Kopete|Rich text support for ICQ|kedgedev@gmail.com|Roman Jarosz}}
{{FeatureInProgress|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Support mms://-protocol, see https://launchpad.net/libmms|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|MLDonkey-Plugin based on libkmldonkey|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Advanced Details|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureInProgress|KRDC|NX support|gdavid.devel@gmail.com|David Gross}}
{{FeatureTodo|KRDC|Minimal-clutter mode to optimize screen real estate usage|gpothier@gmail.com|Guillaume Pothier}}
{{FeatureInProgress|Telepathy|Telepathy-specification compliant Account Manager using KWallet to store account data|grundleborg@googlemail.com|George Goldberg}}
{{FeatureInProgress|Telepathy|Account Editing UI for Telepathy|grundleborg@googlemail.com|George Goldberg}}
{{FeatureInProgress|Plasma|Network Manager Applet|wstephenson@kde.org|Will Stephenson}}
|}
= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Akonadi|Migration of contacts and calendar data from KResource to Akonadi ([http://techbase.kde.org/Projects/PIM/Akonadi#Scheduled_for_4.3 Details])|kde-pim@kde.org|Volker Krause, Kevin Krammer, Tobias Koenig}}
{{FeatureInProgress|Akregator|Support for syncing the feed list with Google Reader |osterfeld@kde.org|Frank Osterfeld}}
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Add export of alarms to a new calendar file|djarvie@kde.org|David Jarvie}}
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Allow configuration of default deferral time interval|djarvie@kde.org|David Jarvie}}
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Accept drag-and-drop of Todo entries to create a new alarm|djarvie@kde.org|David Jarvie}}
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Show command execution error indication in alarm list|djarvie@kde.org|David Jarvie}}
{{FeatureDone|[http://www.astrojar.org.uk/kalarm KAlarm]|Add option to spread alarm windows across screen|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|[http://www.astrojar.org.uk/kalarm KAlarm]|Port to Akonadi|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application|christian_weilbach@.web.de|Christian Weilbach}}
{{FeatureTodo|KBlogger|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}
{{FeatureInProgress|KContactManager|A new Akonadi-based address book to replace KAddressbook|tokoe@kde.org|Tobias Koenig}}
{{FeatureInProgress|Kjots| Create and port to akonadi model. |steveire@gmail.com|Stephen Kelly}}
{{FeatureTodo|Kjots| Add support for nepomuk including tagging, possibly storage, and linking. Also a nepomuk tag proxy model for representing the structure as tagged.|steveire@gmail.com|Stephen Kelly}}
{{FeatureInProgress|Kjots| Create plasmoid capable of showing the entire tree, or a single book.|steveire@gmail.com|Stephen Kelly}}
{{FeatureTodo|Kjots| Email KJots pages using default mail client ({{bug|124509}}. |steveire@gmail.com|Stephen Kelly}}
{{FeatureInProgress|Kleopatra|OpenPGP support|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|KMail|Add support for HTML images|yez@familieschepers.nl|Edwin Schepers}}
{{FeatureTodo|KMail|Use asynchronous Kleo|marc@kdab.net|Marc Mutz}}
{{FeatureTodo|KMail|Save metadata about attachments to Nepomuk when saving them|onurf@su.sabanciuniv.edu|Ismail Onur Filiz}}
{{FeatureTodo|KNode|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|Kontact|Tip-of-the-Day summary|molkentin@kde.org|Daniel Molkentin}}
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureInProgress|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|printer-applet|Restore feature parity with KDEPrint3 where possible.|john@layt.net|John Layt}}
{{FeatureTodo|Okteta|make editing capability to Decoding table |kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for import by drop, both url and data|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|copy again puts also a value or char variant of the data to clipboard|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for memory mapping of files|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add further export formats like s-record and intel 16|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for jobs like io, printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|kwalletmanager|Move kwalletmanager to the Model/View architecture and redesign the UI.|lemma@confuego.org|Michael Leupold}}
{{FeatureInProgress|kdelirc|Bring back kdelirc|michael_zanetti@gmx.net|Michael Zanetti}}
{{FeatureTodo|ark|Improve support for pure gzip and bzip2 files|kubito@gmail.com|Raphael Kubo da Costa}}
{{FeatureInProgress|ark| Finish the cliinterface |haraldhv@stud.ntnu.no|Harald Hvaal}}
{{FeatureTodo|ark| Add lots of more meaningful error messages |haraldhv@stud.ntnu.no|Harald Hvaal}}
{{FeatureTodo|ark| Add support for ACE archives |haraldhv@stud.ntnu.no|Harald Hvaal}}
{{FeatureTodo|ark| Add support for zip archives (cli-based, ie. info-zip) |haraldhv@stud.ntnu.no|Harald Hvaal}}
{{FeatureTodo|KGpg| Port to new systray framework |kde@opensource.sf-tec.de|Rolf Eike Beer}}
{{FeatureTodo|KGpg| Clean up editor GUI and classes |kde@opensource.sf-tec.de|Rolf Eike Beer}}
{{FeatureTodo|KGpg| Make keyserver operations more flexible |kde@opensource.sf-tec.de|Rolf Eike Beer}}
{{FeatureTodo|KGpg| Port key importing to be a transaction |kde@opensource.sf-tec.de|Rolf Eike Beer}}
{{FeatureInProgress|KTimer| Redesign UI |zahl@transbay.net|A. L. Spehr}}
{{FeatureTodo|KTimer| Add hours and seconds to counter |zahl@transbay.net|A. L. Spehr}}
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|krossjava|Integrate into e.g. SuperKaramba and fix issues that show up.|mail@dipe.org|Sebastian Sauer}}
{{FeatureTodo|krossjava|Documentation++|mail@dipe.org|Sebastian Sauer}}
{{FeatureTodo|krossfalcon|Documentation++|mail@dipe.org|Sebastian Sauer}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KGoldrunner|Add Curse of the Mummy game (20 levels), contributed by Steve Mann.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureInProgress|KGoldrunner|Major rewrite, mainly of the game engine and editor.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureInProgress|KGoldrunner|More accurate and reliable pause and resume.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Save and reload at any instant in a game.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Record and replay games.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Run demos ... especially at startup or as hints for difficult levels.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Hot-new-stuff support for themes and game sets.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Integration of the Scavenger game (180 new levels) and its rule-set. This would also involve allowing different grid dimensions for different games, as a feature of the new game engine.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureTodo|KGoldrunner|Better support for beginners, such as graphical cues for false bricks and hidden ladders, extra messages with "don't tell me this again", etc.|ianw2@optusnet.com.au|Ian Wadham}}
{{FeatureInProgress|Killbots|Add "sonic screwdriver" functionality.|parker.coates@gmail.com|Parker Coates}}
{{FeatureTodo|Killbots|Add a tutorial for beginners.|parker.coates@gmail.com|Parker Coates}}
{{FeatureTodo|Kolf|Replace with Kolf 2 (please help!)|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureDone|KPatience|Add a command line switch to manually launch a game of a certain type.|parker.coates@gmail.com|Parker Coates}}
{{FeatureDone|KPatience|Add an option to save the game state at shutdown to be automatically be restored on next run.|parker.coates@gmail.com|Parker Coates}}
{{FeatureDone|KPatience|Add the ability to return to the game selection screen after selecting a game.|parker.coates@gmail.com|Parker Coates}}
{{FeatureTodo|KsirK|rewrite AI code or at least correct most problems related in bug #170777. Volunteers wanted!|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Previous/Next in start new game as described in bug #170774|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Polish the skin editor (doc, contextual help, ...)|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KsirK|Boost playing over Jabber|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|KSpaceDuel|rewrite AI code|dirkrathlev@gmx.de|Dirk Rathlev}}
{{FeatureDone|ktron|Port and remake the KTron game for KDE 4.3|legolas@legolasweb.nl|Stas Verberkt}}
{{FeatureTodo|KSudoku|Import the new logic engine as a library|joselb@gmx.net|Johannes Bergmeier}}
{{FeatureTodo|KSudoku|Port KSudoku to the new engine|joselb@gmx.net|Johannes Bergmeier}}
{{FeatureTodo|KSudoku|Add interactive help|joselb@gmx.net|Johannes Bergmeier}}
{{FeatureDone|Bovo|Add new AI|pelladigabor@gmail.com|Pelladi Gabor}}
{{FeatureDone|Bovo|Computer thinking doesn't block the GUI|pelladigabor@gmail.com|Pelladi Gabor}}
{{FeatureTodo|libkdegames|Import KGGZ libraries from GGZ SVN|spillner@kde.org|Josef Spillner}}
{{FeatureInProgress|libkmahjongg|Introduce new tileset, Bamboo.|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KGrubEditor|Integrate KGrubEditor into KDE Admin http://sourceforge.net/projects/kgrubeditor. Approved by Nicolas Ternisien <nicolas.ternisien@gmail.com> |artemis_dot_fowl_dot_2007@gmail_dot_com|Konstantinos Smanis}}
{{FeatureTodo|Guidance|Port Guidance to KDE 4, and move it to KDE Admin http://www.simonzone.com/software/guidance/.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureTodo|system-config-printer-kde|Restore feature parity with KDEPrint3 where possible.|john@layt.net|john Layt}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|KAppTemplate|Add DBUS support in templates|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureDone|Umbrello|Replace all q3 widgets in the refactoring assistant|andi.fischer@hispeed.ch|Andi Fischer}}
{{FeatureInProgress|Umbrello|Merge in SoC qgraphicsview port branch|krishna.ggk@gmail.com|Gopala Krishna A}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KAlgebra|Export to MathML Presentation Markup|aleixpol@gmail.com|Aleix Pol}}
{{FeatureTodo|KAlgebra|Some integration with the new KFormula widget|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KAlgebra|Add ability to draw 3D plots in cylindrical and spherical coordinates.|orgyforever@gmail.com|Percy Camilo Triveño Aucahuasi}}
{{FeatureTodo|Kalzium|Port Kalzium's periodic table to use new QGraphicsView.|marcus@cryos.org|Marcus D. Hanwell}}
{{FeatureTodo|Kalzium|Remove the libavogadro snapshot, depend on libavogadro directly.|jacob@math.jussieu.fr|Benoit Jacob}}
{{FeatureTodo|Kalzium|Plasmoid to access Kalzium database|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureTodo|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}
{{FeatureTodo|KHangMan|Integrate an editor|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Plasmoid|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Kig|Properties dialog for objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve construction of bisect lines.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve feedback when constructing objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|More geometric objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Script objects as macros (to be reused more than once).|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve the Cabri import filter.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve the new/edit script wizard.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|KLettres|Visual Indicator when letter is wrong|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KLettres|Number support|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KLettres|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KStars|Marble widget for Geolocation tool|mboquien@free.fr|Médéric Boquien}}
{{FeatureTodo|KStars|Better printed star charts|kstars@30doradus.org|Jason Harris}}
{{FeatureTodo|KStars|Sync KStars time from device|mutlaqja@ikarustech.com|Jasem Mutlaq}}
{{FeatureTodo|KStars|Better rendering of comets/asteroids|kstars@30doradus.org|Jason Harris}}
{{FeatureTodo|KStars|Texture mapping of the skymap???|kstars@30doradus.org|Jason Harris}}
{{FeatureTodo|KStars|Improve Observing List Wizard|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Display Comet Magnitudes whenever possible|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Information links in-place for each technical term|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Tool to suggest star-hopping techniques???|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Extend conjunction tool to have one object unspecified, but have a genre of objects specified instead|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Simulate Lunar Eclipses|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Simulate Satellites and Iridium Flares|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KStars|Social and Geographical Integration for KStars|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|Marble|Export map to MxN pixel bitmap|inge@lysator.liu.se|Inge Wallin}}
{{FeatureTodo|Marble|Bookmarks|inge@lysator.liu.se|Inge Wallin}}
{{FeatureTodo|Marble|Support for MarbleWidget::setEnabled( bool )|inge@lysator.liu.se|Inge Wallin}}
{{FeatureTodo|Marble|Map Contents translation|tackat@kde.org|Torsten Rahn}}
{{FeatureTodo|Marble|Editing GeoDataFeatures|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Layer Management Class|rahn@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Plugin architecture for map layers|rahn@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Extending GeoPainter|rahn@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Marble Runners|hdevalence@gmail.com|Henry de Valence}}
{{FeatureInProgress|Marble|GeoClue Integration |jensmh@gmx.de|Jens-Michael Hoffmann}}
{{FeatureInProgress|Marble|Routing |jensmh@gmx.de|Jens-Michael Hoffmann}}
{{FeatureInProgress|Marble|More map providers (WMS?) |jensmh@gmx.de|Jens-Michael Hoffmann}}
{{FeatureInProgress|Marble|Winkel Triple projection / equivalent |hdevalence@gmail.com|Henry de Valence}}
{{FeatureInProgress|Marble|Marble WorldClock Plasmoid|hdevalence@gmail.com|Henry de Valence}}
{{FeatureInProgress|Marble|Qt-Version settings dialog|hdevalence@gmail.com|Henry de Valence}}
{{FeatureInProgress|Marble|Panoramio Support||Shashank Singh}}
{{FeatureInProgress|Marble|Twitter Plugin||Shashank Singh}}
{{FeatureInProgress|Marble|TimeZone Support|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Support for other planets and the moon|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|DGML2 Support|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Support for imperial units|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Graticule plugin|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|MeasureTool plugin|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Port authors list from the Qt-About dialog to the KDE-About dialog|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Basic KML support|ps_ml@gmx.de|Patrick Spendrin}}
{{FeatureInProgress|Marble|GeoData Model/View Visualization|ps_ml@gmx.de|Patrick Spendrin}}
{{FeatureInProgress|Marble|More generic projection support|inge@lysator.liu.se|Inge Wallin}}
{{FeatureInProgress|Marble|Network plugins|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Parley|Declensions|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Step|Improve GUI for creating softbody|ksvladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureTodo|Step|Use common constraints handling code for collisions|ksvladimir@gmail.com|Vladimir Kuznetsov}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|JuK|Remove Qt/KDE3 support lib requirements|michael.pyne@kdemail.net|Michael Pyne}}
{{FeatureTodo|JuK|Allow setting covers directly from URLs supported by KIO - drag/drop already allows this however|michael.pyne@kdemail.net|Michael Pyne}}
{{FeatureDone|JuK|Use XCOMPOSITE real transparency when available for the track announcement popup|michael.pyne@kdemail.net|Michael Pyne}}
{{FeatureTodo|JuK|Allow disabling crossfade|michael.pyne@kdemail.net|Michael Pyne}}
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Okular|Generator for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}
{{FeatureDone|strigi|Thumbnailer and analyzer for Mobipocket format|qbast@go2.pl|Jakub Stachowski}}
{{FeatureDone|strigi|Analyzer for epub format|qbast@go2.pl|Jakub Stachowski}}
{{FeatureTodo|Okular|Sound annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Link annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Caret annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Support .snp and .emf file formats|bradh@kde.org|Brad Hards}}
{{FeatureTodo|Okular|Synctex support.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Rich-text for annotations text.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|kruler|More ruler shapes.|msoeken_at_tzi_dot_de|Mathias Soeken}}
{{FeatureDone|kruler|Configurable shortcuts.|msoeken_at_tzi_dot_de|Mathias Soeken}}
{{FeatureTodo|kruler|DBUS Interface.|msoeken_at_tzi_dot_de|Mathias Soeken}}
{{FeatureDone|kruler|Transparent background and opaque drawing of the lines and numbers (Qt 4.5).|msoeken_at_tzi_dot_de|Mathias Soeken}}
{{FeatureInProgress|gwenview|Folder view.|agateau@kde.org|Aurélien Gâteau}}
{{FeatureInProgress|gwenview|Make thumbnail bar more customizable (orientation, number of rows/columns).|agateau@kde.org|Aurélien Gâteau}}
{{FeatureInProgress|gwenview|Add back video support.|agateau@kde.org|Aurélien Gâteau}}
{{FeatureInProgress|gwenview|Improve history handling.|agateau@kde.org|Aurélien Gâteau}}
{{FeatureDone|libksane|Add "Auto selection" after preview.|kare.sars@iki.fi|Kåre Särs}}
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|drkonqi|DrKonqi new dialog UI + Guided crash reporting tool|andresbajotierra@gmail.com|Dario Andres|}}
{{FeatureInProgress|drkonqi|Backtrace parsing and rating|gkiagiad@csd.uoc.gr|George Kiagiadakis|}}
{{FeatureTodo|drkonqi|DrKonqi native english texts + guide|andresbajotierra@gmail.com|Dario Andres|}}
{{FeatureInProgress|kpasswdserver|Fix D-Bus timeout in kpasswdserver using an async API|lemma@confuego.org|Michael Leupold}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|konq_thumbnails|Basic thumbnail support for KHTMLPart views(almost finished, now cleanup code)|yinshuiboy@gmail.com|Siyuan Cao}}
{{FeatureTodo|konq_thumbnails|thumbnail support for all KonqFrame|yinshuiboy@gmail.com|Siyuan Cao}}
{{FeatureTodo|konq_thumbnails|more thumbnail page styles and customization|yinshuiboy@gmail.com|Siyuan Cao}}
{{FeatureTodo|konqueror|"Places" sidebar to replace KDE3's "media:/"|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}
{{FeatureTodo|konqueror|Move Dolphin's Treeview to libkonq so that it can be used in Konqueror|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}
{{FeatureTodo|konqueror|Move Dolphin's Information panel to libkonq so that it can be used in Konqueror|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}
{{FeatureInProgress|dolphin|Matthias's Audio/ Video preview in Information panel|kdedevel_at_etotheipiplusone_dot_com|Simon St James}}
{{FeatureTodo|dolphin|Allow to configure and download service menus|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|dolphin|Nepomuk search integration|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|dolphin|Use Nepomuk to receive the meta data for the Information panel|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|konsole|Get a working DBus interface|kurt.hindenburg@gmail.com|Kurt Hindenburg}}
{{FeatureTodo|konsole|Redesign manage profile dialog to allow users to sort profiles|kurt.hindenburg@gmail.com|Kurt Hindenburg}}
{{FeatureTodo|konsole|Allow window/terminal size to be set in profiles|kurt.hindenburg@gmail.com|Kurt Hindenburg}}
{{FeatureInProgress|libkonq|Add support in for pluginbased Drag'n'drop popup menus (and in my case, an "extract here" menu on dragged archives)|haraldhv@stud.ntnu.no|Harald Hvaal}}
|}

= kdeplasma-addons =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact

{{FeatureInProgress|Video Plasmoid|a media player widget complete with a basic dbus interface|notmart@gmail.com|Marco Martin}}
{{FeatureDone|System Load Viewer|A tiny monitor for CPU, RAM and swap usage (known as System Monitor in KDE3)|dhaumann@kde.org|Dominik Haumann}}
{{FeatureInProgress|Comic Plasmoid|Clean up the config-dialog|mat69@gmx.net|Matthias Fuchs}}
{{FeatureTodo|Comic Plasmoid|Port to popup applet|mat69@gmx.net|Matthias Fuchs}}
{{FeatureTodo|PoTD Engine|Import PoTD engine|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Metadata Engine|Import Metadata engine|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Frame Plasmoid|Display Picture Metadata|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Frame Plasmoid|Add url as setting|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Frame Plasmoid|Add buttons Next/Previous/pause in slideshow mode|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureInProgress|wallpapers|Mandelbrot fractal wallpaper plugin|jacob.benoit.1@gmail.com|Benoît Jacob}}
{{FeatureInProgress|Weather Wallpaper|Add user-defined wallpapers|echidnaman@kubuntu.org|Jonathan Thomas}}
|}

Schedules/KDE4/4.1 Feature Plan

2008-06-05T00:13:23Z

Mwoehlke: moving my 4.1 planned features...

This is a list of planned features for KDE 4.1. '''The deadline for adding entries to this page has already passed'''.

Any features which are not mentioned on this page must be rescheduled for 4.2 and added to the list at [[Schedules/KDE4/4.2 Feature Plan]].

Please ensure that any entries you have on this page are kept up to date with respect to their status (''todo'', ''in-progress'' or ''done'').

Legend:
* todo => not started yet
* in-progress => started, but not completed yet
* done => completed
__TOC__
= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|various|[[Projects/Widgets_and_Classes | Classes and Widgets]] that should be moved from others modules up into kdelibs|kde-core-devel@kde.org|The Core Developers}}
{{FeatureDone|kdeui|Add KFadeWidgetEffect to easily add fading UI transitions to KDE applications|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|kdeui|Make icon naming spec compliant 3rd party icon themes like Tango or gnome-icon-theme work correctly.|jpetso@gmx.at|Jakob Petsovits}}
{{FeatureDone|kross|Add QtScript support|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|KHTML|Support CSS3 Media Queries|germain@ebooksfrance.org|Germain Garand}}
{{FeatureDone|KHTML|Efficient smooth scrolling|germain@ebooksfrance.org|Germain Garand}}
{{FeatureDone|Phonon KCM|More UI feedback|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|Phonon|better integration of pulseaudio|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|Phonon|allow backend switching on the fly|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|Phonon|subtitle, audio track selection|kretz@kde.org|Matthias Kretz and Ian Monroe}}
{{FeatureTodo|Phonon|DVD menu selection support|imonroe@kde.org|Ian Monroe}}
{{FeatureInProgress|Phonon|update device preference on the fly|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|kdeui|Goya, a framework for inserting controls into itemviews in a really easy and fast way|ereslibre@kde.org|Rafael Fernández López}}
{{FeatureDone | kdeui | Rich textedit widget supporting most rich text features. | steveire@gmail.com | Stephen Kelly }}
{{FeatureInProgress|kdeui|Shortcut schemes for KDE applications|adymo@kdevelop.org|Alexander Dymo}}
{{FeatureDone|kmimetypetrader/kbuildsycoca|Replace use of profilerc for ordering applications with new mimeapps.list standard|faure@kde.org|David Faure}}
{{FeatureDone|knewstuff|Support caching, and speed up the interface through use of Models/Views and goya|jeremy@scitools.com|Jeremy Whiting}}
{{FeatureInProgress|Phonon KCM|Handle advanced devices|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|KDEPrint|Add CUPS Options tabs to QPrintDialog to support n-up, page borders, banner pages, page labels, mirror pages, job scheduling, and manual CUPS options.|john@layt.net|John Layt}}
{{FeatureInProgress|KIO|speed limits on KIO Transfers|nolis71cu@gmail.com|Manolo Valdes}}
{{FeatureInProgress|kdeui|Printing of shortcuts from the shortcut dialog|apaku@gmx.de|Andreas Pakulat}}
{{FeatureDone|Kate Part|Annotation framework for the editor|apaku@gmx.de|Andreas Pakulat}}
{{FeatureInProgress|KJS|Bytecode interpreter and performance improvements|maksim@kde.org|Maks Orlovich}}
{{FeatureInProgress|KHTML|Sync class and file structure with WebKit to prepare merging|porten@kde.org|Harri Porten}}
{{FeatureInProgress|KHTML|contentEditable/designMode implementation|germain@ebooksfrance.org|Germain Garand}}
{{FeatureInProgress|KCalenderSystem|Complete migration of Jalali, Hijri, and Hebrew calendars to new code base.|john@layt.net|John Layt}}
{{FeatureDone|dnssd|Models for service browser and domain browser.|qbast@go2.pl|Jakub Stachowski}}
{{FeatureTodo|KHTML|Adaptable/Scriptable workarounds for broken websites.|maksim@kde.org|Maks Orlovich}}
{{FeatureTodo|KHTML|support for borders-* properties from the CSS3 Background and Borders Module|germain@ebooksfrance.org|Germain Garand}}
{{FeatureInProgress|KHTML|support for Audio/Video tags from the HTML5 draft specification|germain@ebooksfrance.org|Germain Garand}}
{{FeatureDone|KHTML|prospective loading of other network resources while waiting for arrival of blocking scripts|germain@ebooksfrance.org|Germain Garand}}
{{FeatureInProgress|KJS|Public API for extensions. Possibly analog to JavaScriptCore's C API.|porten@kde.org|Harri Porten}}
{{FeatureTodo|KTextEditor|Several interface extensions (e.g. open/save filter)|kwrite-devel@kde.org|Kate Developers}}
{{FeatureTodo|KTextEditor|Plugin for basic collaborative editing|kwrite-devel@kde.org|Kate Developers}}
{{FeatureInProgress|Kate Part|Scripting support for indentation and little helpers|kwrite-devel@kde.org|Kate Developers}}
{{FeatureTodo|Kate Part|Input modes to allow e.g. vim-like editing|kwrite-devel@kde.org|Kate Developers}}
{{FeatureDone|KIO|Implement support for inline editing in KFileItemDelegate|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|KIO|Add support for drawing text shadows in KFileItemDelegate|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|Emoticons lib|An emoticons library so each applications doesn't have to implement the same things over and over again |brandon.ml@gmail.com|Carlo Segato}}
{{FeatureDone|KFile|Implement fd.o desktop-bookmark-spec for KFilePlacesModel|nf2@scheinwelt.at|Norbert Frese}}
{{FeatureTodo|kdeui| Support for About Data of libs and modules used by a program |kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureDone|kdeui|Drop-in replacement for QFontComboBox, with more informative previews in non-Latin1 locales|caslav.ilic@gmx.net|Chusslove Illich}}
{{FeatureDone|KAboutLicense|Select licenses by keyword, to centralize license info texts for frequent licenses.|caslav.ilic@gmx.net|Chusslove Illich}}
{{FeatureDone|KIO|KIO::AuthInfo and PasswordDialog: optional fields (like "domain"); optional anonymous switch and flag to suppress KIO's password caching|nf2@scheinwelt.at|Norbert Frese}}
{{FeatureTodo|kdeui|Support for KConfigGroup in KConfigSkeleton|aseigo@kde.org|Aaron Seigo}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Akonadi|Move the Akonadi development library from kdepim.|vkrause@kde.org|Volker Krause}}
{{FeatureInProgress|Akonadi|Item size ([[Projects/PIM/Akonadi#Core|details]])|thomas.mcguire@gmx.net|Thomas McGuire}}
{{FeatureTodo|Akonadi|Payload serialization format versioning ([[Projects/PIM/Akonadi#Core|details]])|vkrause@kde.org|Volker Krause}}
{{FeatureTodo|Akonadi|Item streaming in ItemSync/ResourceBase ([[Projects/PIM/Akonadi#Core|details]])|tomalbers@kde.nl|Tom Albers}}
{{FeatureInProgress|Akonadi|API for additional item parts ([[Projects/PIM/Akonadi#Core|details]])|vkrause@kde.org,tokoe@kde.org|Volker Krause/Tobias Koenig}}
{{FeatureInProgress|Akonadi|Infrastructure for showing additional dialogs from agents/resources ([[Projects/PIM/Akonadi#Core|details]])|tomalbers@kde.nl|Tom Albers}}
{{FeatureTodo|Akonadi|Allow to limit ItemFetchJob to current cache content ([[Projects/PIM/Akonadi#Core|details]])|vkrause@kde.org|Volker Krause}}
{{FeatureInProgress|Akonadi|Fix API for item/collection modifications ([[Projects/PIM/Akonadi#Core|details]])|vkrause@kde.org|Volker Krause}}
{{FeatureTodo|Akonadi|Error reporting ([[Projects/PIM/Akonadi#Core|details]])|tokoe@kde.org|Tobias Koenig}}
{{FeatureTodo|gpgme++2|newly designed gpgme++ (multithreaded, exceptions, less event loop integration: better for Windows)|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|kpimutils|Change linklocator to use the new emoticon lib|brandon.ml@gmail.com|Carlo Segato}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Dolphin|Details-view: Allow to open folders as tree (turned off per default).|peter.penz@gmx.at|Peter Penz}}
{{FeatureDone|Dolphin|Refactor view-action handling to a DolphinViewActionHandler to share more code with DolphinPart|faure@kde.org|David Faure}}
{{FeatureDone|Konqueror|Re-implement Copy To / Move To in the popup menu|faure@kde.org|David Faure}}
{{FeatureDone|Konqueror|Separate Home URL settings in konquerorrc and kfmrc; save toolbar settings into the profile automatically|faure@kde.org|David Faure}}
{{FeatureDone|Dolphin|Simplify selecting of files in the single-click mode (based on http://aseigo.blogspot.com/2006/04/icons.html).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Raptor|The KDE4-Application-Menu}}
{{FeatureDone|Dolphin|Provide optional tooltips for files and directories.|peter.penz@gmx.at|Peter Penz}}
{{FeatureDone|Dolphin|Tabs|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Konqueror|Bring back the large tooltip like in kde3|faure@kde.org|David Faure}}
{{FeatureDone|Konqueror|Session management (save/restore session/restore from crash).|edulix@gmail.com|Eduardo Robles Elvira}}
{{FeatureDone|Konqueror|Support for undo closed window.|edulix@gmail.com|Eduardo Robles Elvira}}
{{FeatureDone|Konqueror|Allow to configure the Dolphin KPart within the Konquerors settings dialog.|peter.penz@gmx.at|Peter Penz}}
{{FeatureDone|KInfocenter|Improve code and usability.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureDone|KInfocenter|Reimplement partitions list.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureDone|KInfocenter|Reimplement memory module.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureDone|KInfocenter|Reimplement PCI module.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureTodo|KInfocenter|Reimplement Network module.|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Plasma|Kickoff orientation dependent layout|wstephenson@kde.org|Will Stephenson}}
{{FeatureDone|kmenuedit|Restore menu system|montel@kde.org|Laurent Montel}}
{{FeatureDone|KCM autostart|Configure autostart desktop file|montel@kde.org|Laurent Montel}}
{{FeatureDone|Plasma|improve fail to launch and needs
config|aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|ksmserver|UI for selecting WMs|l.lunak@kde.org|Luboš Luňák}}
{{FeatureDone|Plasma|polish kickoff|wstephenson@kde.org|Will Stephenson}}
{{FeatureDone|Plasma|toolbox improvements |aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|Plasma|GHNS2 plasma themes|jeremy@scitools.com|Jeremy Whiting}}
{{FeatureDone|Plasma|Resizable, relocatable panel|binner@kde.org|Stephan Binner}}
{{FeatureInProgress|Solid|Refactor Solid::Control networking|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|Solid|Backend for NetworkManager 0.7|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|System Settings|Filtering/Lazy load category modules|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|KSysGuard|Monitor process I/O|tapsell@kde.org|John Tapsell}}
{{FeatureInProgress|Plasma|Mac-like menu bar plasmoid|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|System Settings|Administrator mode support|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|krunner|Revamp GUI.|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureDone|Plasma|keyboard shortcuts|Chani Armitage|chanika@gmail.com}}
{{FeatureDone|Plasma|webkit widget|aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|Plasma|dashboard widget support|aseigo@kde.org|Aaron Seigo}}
{{FeatureInProgress|Plasma|QtScript scriptengine|richmoore44@gmail.com|Richard Moore}}
{{FeatureInProgress|Plasma|Improve QtScript support|richmoore44@gmail.com|Richard Moore}}
{{FeatureInProgress|Plasma|Zooming User Interface|chanika@gmail.com|Chani Armitage}}
{{FeatureDone|Plasma|Multiple Desktop Containments|chanika@gmail.com|Chani Armitage}}
{{FeatureDone|Plasma|API changes [[Projects/Plasma/Tokamak1]]|panel-devel@kde.org|Plasma team }}
{{FeatureInProgress|Plasma|Panel Toolbox|notmart@gmail.com|Marco Martin}}
{{FeatureInProgress|Plasma|Panel changes to make it work with the new default theme|notmart@gmail.com|Marco Martin}}
{{FeatureInProgress|Plasma|Generic folder view applet/containment, that can also be used as the desktop background (showing the desktop folder).|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|Krunner|Configuration dialog for KRunner|ryan.bitanga@gmail.com|Ryan P. Bitanga}}
{{FeatureDone|Plasma|Temperature sensing in the device engine|cblauvelt@gmail.com|Christopher Blauvelt}}
{{FeatureDone|Plasma|Video data in the device engine|cblauvelt@gmail.com|Christopher Blauvelt}}
{{FeatureTodo|Plasma|New plasma themes|nuno@oxygen-icons.org|Nuno Pinheiro}}
{{FeatureDone|Plasma|change showConfigurationInterfaction to createConfigurationInterface|aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|Plasma|Plasma::Service |aseigo@kde.org|Aaron Seigo}}
{{FeatureTodo|Plasma|panel hiding |aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|KWin|non-linear animations also for KWin|sebas@kde.org|Sebastian Kuegler}}
{{FeatureDone|KWin|Compiz's wobbly like effect for KWin|cedric.borgese@gmail.com|Cédric Borgese}}
{{FeatureTodo|KDM|Theme KDM (login manager) by default|uwolfer@kde.org|Urs Wolfer}}
{{FeatureTodo|Splash screen|New default splashscreen|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureInProgress|Nepomuk|Simple Desktop Search client based on Nepomuk search|trueg@kde.org|Sebastian Trueg}}
{{FeatureInProgress|Plasma|Add a dataengine that implements Notifications DBus interface plasmoid which provides cute visualization of notifications along with nice and easy way to interact with them|dimsuz@gmail.com|Dmitry Suzdalev}}
{{FeatureDone|Plasma|loadDefaultSetup from a file, not hardcoded|aseigo@kde.org|Aaron Seigo}}
{{FeatureDone|ksmserver|Make the fade-to-gray logout effect work even when composite is disabled|fredrik@kde.org|Fredrik Höglund}}
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|nepomuk|Service that monitors file rename and delete operations and updates the metadata accordingly. kded module already exists in playground. problem: depends on inotify.|trueg@kde.org|Sebastian Trueg}}
{{FeatureDone|KCM emoticons|Adding/editing/removing emoticons theme|brandon.ml@gmail.com|Carlo Segato}}
{{FeatureDone|KCM splash screen|Be able to install splash screen themes via GHNS2|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|KCM icons|Be able to install icon themes via GHNS2|mail@dipe.org|Sebastian Sauer}}
{{FeatureInProgress|phonon-xine|snapshots in video widget|kretz@kde.org|Matthias Kretz}}
{{FeatureTodo|phonon-xine|try to make VideoWidget work on GraphicsView|kretz@kde.org|Matthias Kretz}}
{{FeatureTodo|phonon-xine|make states compatible to other backends|kretz@kde.org|Matthias Kretz}}
{{FeatureTodo|phonon-xine|better support for pulseaudio (most work possibly in kdelibs)|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|phonon-gstreamer|Make phonon-gstreamer as released with Qt 4.4 fully integrate into KDE and add the features added to libphonon after libphonon 4.1|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|desktop ioslave|Add an ioslave that lists the contents of the desktop folder, and reports the names in the .desktop files instead of the actual file names.|fredrik@kde.org|Fredrik Höglund}}
{{FeatureDone|knotify|Add support for galago-like desktop notifications spec - if knotify will find a certain DBus service on session bus, it'll forward its popup notification events to this service |dimsuz@gmail.com|Dmitry Suzdalev}}
{{FeatureInProgress|Oxygen cursors|Oxygen cursor set|riccardo@kde.org|Riccardo Iaconelli}}
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KMagnifier|Add color blindness simulation|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KSystemLog|KSystemLog, a Log Viewer Tool. Move from kde-apps|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Do some refactoring in KCron|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Improve ergonomy and general interface|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Fix all existing bugs in KCron|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Convert KCron into a KCM Module, to use it in System Settings|nicolas.ternisien@gmail.com}}
{{FeatureInProgress|Environment Variables|Create a environment variables KCM Module|nicolas.ternisien@gmail.com}}
|}

= kdeartwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Smoke2|Move modular Smoke2 to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureDone|PHP-Qt|Move PHP-Qt to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureDone|krossjava|Move krossjava to kdebindings-trunk.|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|krosspython|Implicit convert PyQt/PyKDE QObject/QWidget instances.|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|krossruby|Implicit convert QtRuby/Korundum QObject/QWidget instances.|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|Qyoto|Add delegate support for signal/slot connections.|kde-bindings@kde.org|KDE-bindings developers}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Kalzium|Clean up the database. I am syncing with the BlueObelisk data repository again. There we decided to remove the density (not a element property but a compound property. I also removed the mean weight. We think it is better to provide correct data than a lot (but partly wrong) data.|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureDone|KAlgebra|Calculator Plasmoid|aleixpol@gmail.com|Aleix Pol}}
{{FeatureDone|KAlgebra|Vector support|aleixpol@gmail.com|Aleix Pol}}
{{FeatureDone|KAlgebra|2D Function support improved|aleixpol@gmail.com|Aleix Pol}}
{{FeatureDone|Step|A physics simulator, move from playground to kdeedu module |ks.vladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureDone|Kalzium|Update the snapshot of libavogadro to 0.6.1. This introduces a gazillion new possibilities for the 3D renderer and fixes many issues.|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureDone|Kalzium|Make use of the new libavogadro-version.|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureDone|Kalzium|Expose molecular editing features of libavogadro.|marcus@cryos.org|Marcus D. Hanwell}}
{{FeatureInProgress|KStars|Tool to predict Conjunctions|akarshsimha@gmail.com|Akarsh Simha}}
{{FeatureInProgress|Marble|DGML2 Support|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|KDE-Version settings dialog|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Port authors list from the Qt-About dialog to the KDE-About dialog|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Qt-Version settings dialog|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Improved KML support|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|OpenStreetMap support using original OSM tiles|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Real Time Cloud-Cover|tackat@kde.org|David Roberts / Torsten Rahn}}
{{FeatureTodo|Marble|Map Contents translation|tackat@kde.org|Torsten Rahn}}
{{FeatureDone|Marble|Copy position to clipboard|tackat@kde.org|Torsten Rahn}}
{{FeatureDone|Marble|Create Tiles on compile time|tackat@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Mercator Projection|inge@lysator.liu.se|Inge Wallin}}
{{FeatureInProgress|Marble|More generic projection support|inge@lysator.liu.se|Inge Wallin}}
{{FeatureInProgress|Marble|Usage of Marble in non-widgets|inge@lysator.liu.se|Inge Wallin}}
{{FeatureTodo|Marble|Export map to MxN pixel bitmap|inge@lysator.liu.se|Inge Wallin}}
{{FeatureTodo|Marble|Support for MarbleWidget::setEnabled( bool )|inge@lysator.liu.se|Inge Wallin}}
{{FeatureInProgress|Marble|Layer Management Class|rahn@kde.org|Torsten Rahn}}
{{FeatureInProgress|Marble|Plugin architecture for map layers|rahn@kde.org|Torsten Rahn}}
{{FeatureInProgress|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}
{{FeatureDone|Parley|Redesigned main window|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureDone|Parley|Vocabulary Plasmoid|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|Kalzium|Plasmoid to access Kalzium database|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureDone|Step|Improve GUI for creating gas|ksvladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureDone|KAlgebra|Variables share between 2D and Console|aleixpol@gmail.com|Aleix Pol}}
{{FeatureTodo|KTurtle|Export canvas as image|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Add command line|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Add a color picker|nielsslot@gmail.com|Niels Slot}}
{{FeatureInProgress|Parley|Declensions|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|Parley|Improved printing support|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureDone|Kiten|Link radselect with kiten|jkerian@gmail.com|Joe Kerian}}
{{FeatureDone|Kiten|Sort output by dictionary/user selected sorting values|jkerian@gmail.com|Joe Kerian}}
{{FeatureDone|Kig|Cubic-line intersection in case two of the three intersection points are already present|paolini@dmf.unicatt.it|Maurizio Paolini}}
{{FeatureTodo|Kig|Properties dialog for objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve construction of bisect lines.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve feedback when constructing objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|More geometric objects.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Script objects as macros (to be reused more than once).|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Kig|Improve the Cabri import filter.|pino@kde.org|Pino Toscano}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KDiamond|New game, move to kdegames|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureDone|KDiamond|Get themes with KNewStuff|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureDone|KNetWalk|Better scoring system|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureDone|KNetWalk|Add support for loading new themes|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureDone|Kollision|Move to kdereview/kdegames|p.capriotti@gmail.com|Paolo Capriotti}}
{{FeatureDone|Kubrick|New game, 3D OpenGL - move to playground|ianw}}
{{FeatureDone|Kubrick|Polish up the features|ianw}}
{{FeatureDone|Kubrick|Port to Qt4 and KDE4|ianw}}
{{FeatureDone|KBlocks|Finish display of points and level|piacentini@kde.org}}
{{FeatureDone|KBlocks|Implement KNewStuff support|piacentini@kde.org}}
{{FeatureDone|KBlocks|Implement key/action/shortcut configuration|piacentini@kde.org}}
{{FeatureDone|KBlocks|Docbook|piacentini@kde.org}}
{{FeatureInProgress|KGoldRunner|Improved theming and animation|mikelima@cirulla.net}}
{{FeatureInProgress|KGoldRunner|Sound support and theming|mikelima@cirulla.net}}
{{FeatureInProgress|KSquares|Multiplayer support|josef}}
{{FeatureDone|KsirK|New game, move to kdereview|kleag@free.fr|Gaël de Chalendar}}
{{FeatureDone|KsirK|Make network games work again|kleag@free.fr|Gaël de Chalendar}}
{{FeatureDone|KBattleship|Bring back Zeroconf support for network games|qbast@go2.pl}}
{{FeatureInProgress|Kubrick|New game, 3D OpenGL - in kdereview|ianw}}
{{FeatureInProgress|KGGZ|Add kggzcore and kggzdmod libraries|josef}}
{{FeatureTodo|KBlocks|Add additional themes|piacentini@kde.org}}
{{FeatureInProgress|KBreakout|Finish it, and move it from playground to kdegames|fela.kde@gmail.com}}
{{FeatureTodo|KGGZ|Add new Qt4-based core client as successor to the old KDE3-based KGGZ|josef (now SoC proposal)}}
{{FeatureTodo|KGGZ|Fire-and-forget highscore submission for single-player games and client-to-client multiplayer games|josef)}}
{{FeatureTodo|KGoldRunner|Also see kdegames/kgoldrunner/TODO|ianw}}
{{FeatureTodo|KGoldRunner|Hot new stuff support for themes and levels|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Startup screen|mikelima@cirulla.net}}
{{FeatureTodo|KMahjongg|Reimplement the Board Editor|piacentini@kde.org}}
{{FeatureDone|KMines|Add pause actions|eike.lange@kdemail.net}}
{{FeatureDone|KNetWalk|Configurable keyboard support|eike.lange@kdemail.net}}
{{FeatureTodo|KNetWalk|Support for custom and non-square board sizes|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureTodo|KShisen|Port to KScoreDialog|piacentini@kde.org}}
{{FeatureTodo|Kubrick|See SVN file kubrick/TODO|ianw}}
{{FeatureDone|Kubrick|Move to KDE Games for 4.1|ianw}}
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Gwenview|Undo system|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureDone|Gwenview|Fullscreen meta information|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureDone|Gwenview|Ability to open an image with another application|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureDone|Okular|Better Text-To-Speech integration: speech the whole document, the current page or the selection.|pino@kde.org|Pino Toscano}}
{{FeatureDone|Okular|Encryption support for ODF generator|bradh@kde.org}}
{{FeatureDone|Okular|Backward direction for text search.|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|Centralized text & graphics antialias configuration.|pino@kde.org|Pino Toscano}}
{{FeatureDone|Okular|EPub backend.|elylevy@cs.huji.ac.il|Ely Levy}}
{{FeatureInProgress|Okular|Improved form support (add missing types, handle the fields better).|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Gwenview|Support for tagging with Nepomuk|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureInProgress|Gwenview|Thumbnail bar in view and fullscreen modes|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureDone|Gwenview|Crop ratio|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|KIPI support|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|Red eye correction|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|Start page|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureInProgress|Okular|JavaScript support (mostly for PDF documents).|pino@kde.org|Pino Toscano}}
{{FeatureDone|Okular|Improved placement and sizing of the presentation mode: choose the screen to use, adapt to screen size changes.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Caret annotations.|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|File attachment annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Sound annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Link annotations.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Improve annotation support: for existing types (rubber stamps, line, note, etc), and for the way they are constructed and handled.|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|Separate the "view properties" out of the Document, in a View class. Use it for the page view and the presentation mode.|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Okular|Per-document zoom level.|pino@kde.org|Pino Toscano}}
{{FeatureDone|libksane|Move libksane to kdegraphics|kare.sars@kolumbus.fi|Kåre Särs}}
{{FeatureDone|ksaneplugin|Replase libkscan with ksaneplugin|kare.sars@kolumbus.fi|Kåre Särs}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Dragon Player|A simple Phonon-based videoplayer application|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|Make Dragon indipendent from Xine|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|File Manager|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|play media dialog|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|slider changes|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|show info while playing audio files|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureDone|JuK|Show cover art from more sources|michael.pyne@kdemail.net|Michael Pyne}}
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KGet|Group-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Torrent-Support|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Transfer-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Webinterface|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|Kopete|AIM offline messages|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureDone|Kopete|OTR Encryption support|michael_zanetti@gmx.net|Michael Zanetti}}
{{FeatureDone|Kopete|Status manager|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureDone|Kopete|Non-intrusive notification system|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureDone|Kopete|Bring back chat style selection via knewstuff2|earthwings@gentoo.org|Dennis Nienhüser}}
{{FeatureInProgress|Kopete|ICQ 6 status icons|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureInProgress|Kopete|Use notebook lid for auto away|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureDone|Kopete|use the new emoticons library|brandon.ml@gmail.com|Carlo Segato}}
{{FeatureDone|KGet|Nepomuk-Integration|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Global Speedlimits|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Setup libbtcore from KTorrent in KGet (to avoid dependency to extragear)|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|KGet|Extend the TransferHistory to use SQLite and XML-Backends and display the information inside a kcategorizedview|jgoday@gmail.com|Javier Goday}}
{{FeatureTodo|Kopete|GroupWise chatroom support|wstephenson@kde.org|Will Stephenson}}
{{FeatureTodo|[http://decibel.kde.org Decibel]|Decibel, a framework for real time communication services. Move from playground/pim|info@basyskom.de|Tobias Hunger}}
{{FeatureDone|KRDC|Optional system tray icon (with quick access to bookmarks)|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|KRDC|Improved behavior of entering special keys for better workflow|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|KRDC|Zeroconf support (detecting remote desktop services in local network)|romnes@stud.ntnu.no|Magnus Romnes}}
{{FeatureInProgress|KRDC|Bookmark dock widget for quick access to bookmars, zero conf detected services and recently used connections|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|KRDC|Support for up- and downscaling VNC remote desktop|uwolfer@kde.org|Urs Wolfer}}
{{FeatureInProgress|Plasma|Network Manager Applet|cblauvelt@gmail.com|Christopher Blauvelt}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KAddressbook|Ability to add LDAP search results to distribution lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Indication of which resource folder a contact belongs to|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Read-only view for contacts in read-only folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|copy/cut/paste context menu items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAlarm|Allow use of multiple calendar resources|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Handle time zones and seasonal time changes properly|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Abolish alarm daemon and make kalarm trigger alarms itself|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Replace simple repetitions by recurrence sub-repetitions to reduce confusion|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|New option for display alarm text to be generated by a command|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Option to display alarm only if pre-alarm command succeeded|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|New option to specify reminder times in minutes|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Prevent multiple identical error messages accumulating for the same alarm|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Provide "don't show again for this alarm" option for command error messages|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Remember main window show/hide options used when KAlarm closed instead of setting them in Preferences dialog|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Simplification and improvements to alarm edit dialog|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KAlarm|Option to display alarms in centre of screen, with enable delay on buttons to avoid accidental acknowledgement|djarvie@kde.org|David Jarvie}}
{{FeatureDone|KJots|Support more rich text features like text formatting, hyperlinks and ordered/unordered lists.|steveire@gmail.com|Stephen Kelly}}
{{FeatureDone|KJots|Add checkmarks to pages.|steveire@gmail.com|Stephen Kelly}}
{{FeatureDone|KJots|Port to KRichText widget.|steveire@gmail.com|Stephen Kelly}}
{{FeatureDone|KJots|Create a Kontact::Plugin to integrate kjots into Kontact.|steveire@gmail.com|Stephen Kelly}}
{{FeatureDone|Kleopatra|Ability to search in internal and external certificates at the same time|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kleopatra|General UI Server|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|Kleopatra|New, tabbed, mainwindow design|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|KMail|Ability to create hyperlinks in HTML messages|steveire@gmail.com|Stephen Kelly}}
{{FeatureDone|KMail|Ability to easily create todos with reminders from emails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to open messages from search results when the reader is hidden|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better invitation update emails showing what changed|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better reminder visualization in very small events|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better, natural language search criteria names|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Clickable status columns|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Client side configurability of warnings in shared folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Colored ribbons for indication of signing and encryption status in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Configuration option for whether invitation emails are automatically deleted or not when having been acted upon|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Copy/paste and drag and drop from/to the mail composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Decryption on demand in reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Display of quota information in foldertree tooltips|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop and copy and paste support in the search result viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop from the mail reader window and mime-tree viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop of folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Editing of attachments from the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Export and import of filters|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Favorites Folder|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Folder quicksearch|m.koller@surfeu.at|Martin Koller}}
{{FeatureDone|KMail|Harmonization of actions in main and standalone mail reader windows|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|IMAP Server storage of non-standard flags|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved TNEF attachment handling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved quota warnings|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Initialize full search from quicksearch on request|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Override font and fontsize for standalone message viewers|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Per-folder identity configurability|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Recursive IMAP cache troubleshooting|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Resizable recipients area in composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for creating new mails based on received mails (Resend)|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for immediate sync of resource folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for soft line breaking|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Tab navigation through groups in the address completion|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Text snippets with shortcuts and variable expansion in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Warning about active out-of-office scripts|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|lost+found recovery of locally changed folders that lose access rights|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Port to use KRichTextEdit||Thomas McGuire}}
{{FeatureDone|KNotes|Ability to print notes|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KonsoleKalendar|Support "file" and "localdir" resources|winter@kde.org|Allen Winter}}
{{FeatureDone|Kontact|Config option to close despite system tray|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Harmonization of component naming in sidebar, configuration, summary view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Right-aligned component navigation toolbar|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Ubiquitous sync actions|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Ability to have both distribution lists and addresbook extension visible|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Aggregated reminders view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Better default resource colors|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Drag and drop of attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Faster initial loading of kolab resources|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Forwarding and delegation of invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved coloring of agenda view items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved event printing|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Merge of the attachment view in into the main page|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Merge of the free-busy and attendee views for easier scheduling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Month view scrolling, paging, mouse-wheeling|tom_t@gmx.at|Thomas Thrainer}}
{{FeatureDone|KOrganizer|More readable Kolab resource folder labels|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Redesigned incidence editor UI|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Side-by-side calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Support for by-value attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Timeline calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Rich text incidence editor|mike@mikearthur.co.uk|Mike Arthur}}
{{FeatureDone|KOrganizer|Hide/Show reminder daemon icon in the systeay|winter@kde.org|Allen Winter}}
{{FeatureDone|KOrganizer|New To-do View (model/view)|tom_t@gmx.at|Thomas Thrainer}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Column-specific whatsthis-help| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Combined search and add task widget| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Drag&Drop| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|File management (file->load)| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Managing history| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Tracking tasks by active applications| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Whatsthis-help dependent on if a task has been created| |Thorsten Stärk}}
{{FeatureInProgress|Akregator|Support for syncing the feed list with Google Reader |osterfeld@kde.org|Frank Osterfeld}}
{{FeatureInProgress|KAlarm|New option to restrict alarms to working hours|djarvie@kde.org|David Jarvie}}
{{FeatureInProgress|Kleopatra|OpenPGP support|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureInProgress|KMail|HTML Signatures|yez@familieschepers.nl|Edwin Schepers}}
{{FeatureInProgress|KNotes|Zeroconf support for sending notes on LAN|qbast@go2.pl|Jakub Stachowski}}
{{FeatureInProgress|Kontact|New Planner summary; combines Appointment+To-do+SpecialDates into 1 pretty summary|winter@kde.org|Allen Winter}}
{{FeatureInProgress|KOrganizer|New Month View (qgraphicsitem)|bvirlet@kdemail.net|Bruno Virlet}}
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureTodo|Akregator|Basic support for enclosures (Displaying links, mimetype and size)|osterfeld@kde.org|Frank Osterfeld}}
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application| christian_weilbach@.web.de|Christian Weilbach}}
{{FeatureTodo|Kleopatra|Konqueror and Dolphin Kleopatra plugins|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureTodo|KMail|Aggregated attachment view in the mail header area of the reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Improved error messages and audit log for cryptographic operations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Ability to jump to the right day in the agenda from invitation mails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop in the free-busy view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for comments in replies to invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Blog-styled journal view|mike@mikearthur.co.uk|Mike Arthur}}
{{FeatureTodo|KOrganizer|Blogging KResource|mike@mikearthur.co.uk|Mike Arthur}}
{{FeatureTodo|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureTodo|KBlogger|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}
{{FeatureTodo|KNode|Port to use KRichTextEdit (Or KMEditor)|steveire@gmail.com|Stephen Kelly}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Cervisia|New context menu entry "Add to Ignore List"|christian.loose@hamburg.de|Christian Loose}}
{{FeatureDone|Lokalize|Move this application (formerly known as Kaider) from extragear|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Cervisia|A file view based on KDirModel|christian.loose@hamburg.de|Christian Loose}}
{{FeatureInProgress|KBugBuster|Make it work|fabiolocati@gmail.com|Fabio Locati}}
{{FeatureInProgress|KCachegrind|Everything working again|josef.weidendorfer@gmx.de|Josef Weidendorfer}}
{{FeatureInProgress|Kate|Session plasmoid|montel@kde.org|Laurent Montel}}
{{FeatureDone|KAppTemplate|Make a GUI for it |annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureDone|KAppTemplate|Add a PyQt4 template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureDone|KAppTemplate|Add a Ruby template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureDone|KAppTemplate|Add a Plasmoid template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KCachegrind|Better handling of huge symbols|josef.weidendorfer@gmx.de|Josef Weidendorfer}}
{{FeatureTodo|kioslave svn|Add Export/Import feature|montel@kde.org|Laurent Montel}}
{{FeatureTodo|Kate App|Improved session management|kwrite-devel@kde.org|Kate Developers}}
|}

= kdetoys =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|printer-applet|Add printer applet for viewing print jobs and printer auto-configuration.|jriddell@ubuntuFIXMEcom|Jonathan Riddell}}
{{FeatureDone|Okteta|binary/hex editor (successor to KHexEdit). Move from playground/utils.|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureDone|Okteta|enable extract-strings tool and add copy|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureDone|Okteta|add "Export as"|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureDone|Okteta|make printing support only selection|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|ask artists for own icon|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|more explicit titels for undo/redo actions, also from filters|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for blocking processes like printing, string search or filter|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureInProgress|KDiskFree|Use Solid API|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureTodo|KwikDisk|Replace it by a Plasmoid (in the desktop bar and on the desktop|nicolas.ternisien@gmail.com|Nicolas Ternisien}}
{{FeatureDone|SuperKaramba|Integrate Kross and be able to write Karambas using Python, Ruby and JavaScript||The SuperKaramba Team}}
{{FeatureDone|SuperKaramba|Integrate into Plasma||The SuperKaramba Team}}
|}

= kdevelop =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdevplatform =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdewebdev =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Kommander|Port the executor to KDE4.|amantia@kde.org|Andras Mantia}}
{{FeatureTodo|Kommander|Create Qt Designer plugins for the editor.|amantia@kde.org|Andras Mantia}}
{{FeatureInProgress|Quanta Plus|Create an upload plugin.| niko.sams@gmail.com|Niko Sams}}
{{FeatureInProgress|Quanta Plus|Create a new, state machine based parser.| amantia@kde.org|Andras Mantia}}
{{FeatureInProgress|Quanta Plus|Port existing functionality to KDevPlatform plugins. Only text mode is targeted.|amantia@kde.org|Andras Mantia}}
{{FeatureDone|KXslDbg|Port to KDE4.|keith@kdewebdev.org |
Keith Isdale}}
{{FeatureTodo|KLinkStatus|Aided correction of broken links||}}
{{FeatureDone|KLinkStatus|Site check automation|moura@kdewebdev.org|Paulo Moura Guedes}}
{{FeatureInProgress|KLinkStatus|D-Bus/Scripting interfaces|moura@kdewebdev.org|Paulo Moura Guedes}}
{{FeatureInProgress|KLinkStatus|HTML validation|thesquib@gmail.com|Sam Ryan}}
{{FeatureDone|KLinkStatus|Ability to export only broken links|moura@kdewebdev.org|Paulo Moura Guedes}}
{{FeatureDone|KLinkStatus|Ability to do background search which only update the GUI when finished (much faster))|moura@kdewebdev.org|Paulo Moura Guedes}}
{{FeatureDone|KLinkStatus|Tray Icon and KUniqueApplication|Paulo Moura Guedes}}
{{FeatureDone|KLinkStatus|Scripting Plugin|Paulo Moura Guedes}}
{{FeatureDone|KLinkStatus|Get Hot New Stuff for HTML result stylesheets|Paulo Moura Guedes}}
|}

Schedules/KDE4/4.2 Feature Plan

2008-06-05T00:11:11Z

Mwoehlke: moving my 4.1 planned features...

This is a list of planned features for the 4.2 release.

See also:
* [[Schedules/KDE4/4.2 Release Schedule]]
* [[Schedules/KDE4/4.1 Feature Plan]]
* [[Schedules/KDE4/Goals]]

Legend:
* todo => not started yet
* in-progress => started, but not completed yet
* done => completed
__TOC__

= Other =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|System Settings|add Administrator mode button|?|?}}
{{FeatureInProgress|Eigen|Finish version 2.0 and move it to kdesupport|jacob@math.jussieu.fr|Benoît Jacob}}
{{FeatureTodo|Eigen|Port all Eigen-using code in KDE and KOffice to Eigen 2.0|jacob@math.jussieu.fr|Benoît Jacob}}
|}

= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|kross|Extend QtScript integration.|mail@dipe.org|Sebastian Sauer}}
{{FeatureInProgress|KDEPrint|Reintroduce KDEPrint in some form, depending on what Qt4.4 delivers.|john@layt.net|john Layt}}
{{FeatureTodo|KDEPrint|Add framework for standard actions for 'Send to...' for e-mail, fax, etc by printing to PDF/PS.|john@layt.net|John Layt}}
{{FeatureTodo|KDEPrint|Migrate FilePrinter class from Okular to enable file printing for all apps via QPrinter, modify to utilise new Qt4.4 features. To be discussed on k-c-d first.|john@layt.net|John Layt}}
{{FeatureTodo|KCalenderSystem|Add new calendar systems: Indian Civil (Saka), Ethiopean, Chinese, Pure Julian, Pure Gregorian. (Note, not all may live in kdelibs or be available as a global calendar system)|john@layt.net|John Layt}}
{{FeatureTodo|KLocale|Implement KLocale based methods to return weekend days and day of religious observance. Currently KCalendarSystem provides dayOfPray(), but for Gregorian this is not correct in all locales where it is used. Currently KDatePicker hardcodes Saturday and dayOfPray() as weekend days which may not be correct in all locales. To be discussed first on k-c-d and with kdepim.|john@layt.net|John Layt}}
{{FeatureTodo|Phonon|add Port class for fine grained control over data flow between Phonon objects|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|Phonon|make AbstractMediaStream/StreamInterface threadsafe|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|Phonon|"low-level" PCM I/O with at least an ALSA implementation|kretz@kde.org|Matthias Kretz and Ian Monroe}}
{{FeatureInProgress|Phonon|VideoWidget snapshot function|kretz@kde.org|Matthias Kretz}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KDEPrint|reintroduce KDEPrint Print Management tools, e.g. KCM, kprinter, kjobviewer, etc. Depends upon progress of kdelibs side of KDEPrint and Qt4.4 feature set.|john@layt.net|john Layt}}
{{FeatureInProgress|Plasma|welcome plasmoid|aseigo@kde.org|Aaron Seigo}}
{{FeatureInProgress|Plasma|Plasmagik packaging (and package classes)|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureInProgress|Plasma|Networkmanager Plasmoid and DataEngine|cblauvelt@gmail.com|Christopher Blauvelt}}
{{FeatureInProgress|Krunner|Configuration options for blacklisting, user ranking, runner ranking, learning|mumismo@gmail.com|Jordi Polo}}
{{FeatureTodo|Krunner|Simple learning|mumismo@gmail.com|Jordi Polo}}
{{FeatureTodo|Krunner|Simple GUI for above options|mumismo@gmail.com|Jordi Polo}}
{{FeatureTodo|Krunner|Runners able to share parsing|mumismo@gmail.com|Jordi Polo}}
{{FeatureTodo|Krunner|Noun-Verb support|ryan.bitanga@gmail.com|Ryan P. Bitanga}}
{{FeatureTodo|Plasma|physics-based animator|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureTodo|Plasma|Improve the base set of plasmoids|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureTodo|Plasma|New wallpapers|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureTodo|Plasma|New way of handling wallpapers and different sizes (package format, and so on...)|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureTodo|Plasma|Top-level windows plasmoids|riccardo@kde.org|Riccardo Iaconelli}}
{{FeatureTodo|Color KCM|Add 'smart setting' of extended colors|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|Color KCM|Add KDE3 scheme import|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|Color KCM|Query kwin for supported colors; add full set of kwin colors|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Kopete|MSNP15 implementation for MSN|mattr@kde.org|Matt Rogers}}
{{FeatureInProgress|Kopete|UPnp Support|mattr@kde.org|Matt Rogers}}
{{FeatureInProgress|Kopete|Updated contact list interface (uses Qt 4 rather than Qt 3)|mattr@kde.org|Matt Rogers}}
{{FeatureTodo|Kopete|Update Kopete to better support Decibel|kopete-devel@kde.org|Kopete Developers}}
{{FeatureInProgress|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureInProgress|KGet|Support mms://-protocol, see https://launchpad.net/libmms|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|MLDonkey-Plugin based on libkmldonkey|l.appelhans@gmx.de|Lukas Appelhans}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Kjots| Import notes from KNotes as KJots pages. |steveire@gmail.com|Stephen Kelly}}
{{FeatureTodo|Kjots| Email KJots pages using default mail client ({{bug|124509}}. |steveire@gmail.com|Stephen Kelly}}
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Power Manager|import either Guidance Power Manager or move kde4powersaver into kdeutils|?|?}}
{{FeatureTodo|Okteta|add Kate-like search tool|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|refactor KByteArrayView|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|add support for memory mapping of files|kossebau@kde.org|Friedrich W. H. Kossebau}}
{{FeatureTodo|Okteta|parameter dialog for "Copy as..."|kossebau@kde.org|Friedrich W. H. Kossebau}}
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Smoke|Wrap some more APIs (at least Akanodi for all languages and Plasma for C#)|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureTodo|krossjava|Integrate into e.g. SuperKaramba and fix issues that show up.|mail@dipe.org|Sebastian Sauer}}
{{FeatureTodo|krossjava|Documentation++|mail@dipe.org|Sebastian Sauer}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|libkdegames|New highscore management system|milliams|Matt Williams}}
{{FeatureTodo|kdiamond|Drag jewels|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureTodo|kdiamond|Optional OpenGL rendering|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureInProgress|ksirk|Map scrolling arrows|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|ksirk|KHotNewStuff skins|kleag@free.fr|Gaël de Chalendar}}
{{FeatureTodo|ksirk|Jabber based net game finding|kleag@free.fr|Gaël de Chalendar}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Kate|Port and reenable the Snippets plugin.|jpetso@gmx.at|Jakob Petsovits}}
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|KAppTemplate|Add DBUS support in templates|annma@kde.org|Anne-Marie Mahfouf}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KLettres|Number support|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KLettres|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Add a Open File action|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Integrate an editor|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Plasmoid|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KHangMan|Theme manager|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KLettres|Visual indicator when letter is wrong|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Kalzium|Port Kalzium's periodic table to use new QGraphicsView.|marcus@cryos.org|Marcus D. Hanwell}}
{{FeatureTodo|Step|Improve GUI for creating softbody|ksvladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureTodo|Step|Use common constraints handling code for collisions|ksvladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureInProgress|KAlgebra|New parser using QLALR|aleixpol@gmail.com|Aleix Pol}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Dragon Player|Make Dragon indipendent from Xine|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|File Manager|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|play media dialog|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|slider changes|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|show info while playing audio files|ian.monroe@gmail.com|Ian Monroe}}
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|KMagnifier|Refactor color menu, re-add invert, break current color blindness code into "daltonize" and "simulate"|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|KMagnifier|Add color-shift modes to help people with color blindness|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

Schedules/KDE4/4.1 Feature Plan

2008-03-21T17:44:39Z

Mwoehlke: /* kdebase-workspace */

This is a list of planned features. The deadline for adding entries here for the 4.1 release is '''31 March 2008'''.

Entries added after that date will be scheduled for the 4.2 release.

Legend:
* todo => not started yet
* in-progress => started, but not completed yet
* done => completed
__TOC__
= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|kdeui|Add KFadeWidgetEffect to easily add fading UI transitions to KDE applications|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|kross|Add QtScript support|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|Phonon KCM|More UI feedback|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|kdeui|Goya, a framework for inserting controls into itemviews in a really easy and fast way|ereslibre@kde.org|Rafael Fernández López}}
{{FeatureInProgress|kdeui|Shortcut schemes for KDE applications|adymo@kdevelop.org|Alexander Dymo}}
{{FeatureInProgress|kmimetypetrader/kbuildsycoca|Replace use of profilerc for ordering applications with new mimeapps.list standard|faure@kde.org|David Faure}}
{{FeatureInProgress|knewstuff|Support caching, and speed up the interface through use of Models/Views and goya|jeremy@scitools.com|Jeremy Whiting}}
{{FeatureInProgress|Phonon KCM|Handle advanced devices|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|KDEPrint|Reintroduce KDEPrint in some form, depending on what Qt4.4 delivers.|john@layt.net|john Layt}}
{{FeatureInProgress|KIO|speed limits on KIO Transfers|nolis71cu@gmail.com|Manolo Valdes}}
{{FeatureInProgress|kdeui|Printing of shortcuts from the shortcut dialog|apaku@gmx.de|Andreas Pakulat}}
{{FeatureTodo|KCalenderSystem|Complete migration of Jalali, Hijri, and Hebrew calendars to new code base.|john@layt.net|john Layt}}
{{FeatureTodo|KCalenderSystem|Add new calendar systems: Indian Civil (Saka), Ethiopean, Chinese, Pure Julian, Pure Gregorian. (Note, not all may live in kdelibs or be available as a global calendar system)|john@layt.net|john Layt}}

|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Akonadi|Move the Akonadi development library from kdepim.|vkrause@kde.org|Volker Krause}}
{{FeatureTodo|gpgme++2|newly designed gpgme++ (multithreaded, exceptions, less event loop integration: better for Windows)|marc@kdab.net|Marc Mutz (Gpg4win)}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Dolphin|Details-view: Allow to open folders as tree (turned off per default).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Dolphin|Refactor view-action handling to a DolphinViewActionHandler to share more code with DolphinPart|faure@kde.org|David Faure}}
{{FeatureInProgress|Dolphin|Simplify selecting of files in the single-click mode (based on http://aseigo.blogspot.com/2006/04/icons.html).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Raptor|The KDE4-Application-Menu}}
{{FeatureTodo|Dolphin|Provide optional tooltips for files and directories.|peter.penz@gmx.at|Peter Penz}}
{{FeatureTodo|Konqueror|Session management (save/restore session/restore from crash).|edulix@gmail.com|Eduardo Robles Elvira}}
{{FeatureInProgress|Konqueror|Support for undo closed window.|edulix@gmail.com|Eduardo Robles Elvira}}
{{FeatureTodo|Konqueror|Allow to configure the Dolphin KPart within the Konquerors settings dialog.|peter.penz@gmx.at|Peter Penz}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Plasma|Kickoff orientation dependent layout|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|Solid|Refactor Solid::Control networking|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|Solid|Backend for NetworkManager 0.7|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|System Settings|Filtering/Lazy load category modules|wstephenson@kde.org|Will Stephenson}}
{{FeatureInProgress|KCM autostart|Configure autostart desktop file|montel@kde.org|Laurent Montel}}
{{FeatureInProgress|KCM emoticons|Adding/editing/removing emoticons theme|brandon.ml@gmail.com|Carlo Segato}}
{{FeatureTodo|Color KCM|Add 'smart setting' of extended colors|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|Color KCM|Add KDE3 scheme import|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|Color KCM|Query kwin for supported colors; add full set of kwin colors|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|KDEPrint|reintroduce KDEPrint Print Management tools, e.g. KCM, kprinter, kjobviewer, etc. Depends upon progress of kdelibs side of KDEPrint and Qt4.4 feature set.|john@layt.net|john Layt}}
{{FeatureTodo|System Settings|Administrator mode support|wstephenson@kde.org|Will Stephenson}}
{{FeatureTodo|krunner|Revamp GUI.|riccardo@kde.org|Riccardo Iaconelli}}
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|nepomuk|Service that monitors file rename and delete operations and updates the metadata accordingly. kded module already exists in playground. problem: depends on inotify.|trueg@kde.org|Sebastian Trueg}}
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KMagnifier|Add color blindness simulation|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|KMagnifier|Refactor color menu, re-add invert, add color-shift modes to help people with color blindness|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KSystemLog|KSystemLog, a Log Viewer Tool. Move from kde-apps|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Do some refactoring in KCron|nicolas.ternisien@gmail.com}}
{{FeatureInProgress|KCron|Improve ergonomy and general interface|nicolas.ternisien@gmail.com}}
{{FeatureInProgress|KCron|Fix all existing bugs in KCron|nicolas.ternisien@gmail.com}}
{{FeatureDone|KCron|Convert KCron into a KCM Module, to use it in System Settings|nicolas.ternisien@gmail.com}}
{{FeatureTodo|Environment Variables|Create a environment variables KCM Module|nicolas.ternisien@gmail.com}}
|}

= kdeartwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Smoke2|Move Smoke2 to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureTodo|PHP-Qt|Move PHP-Qt to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Kalzium|Clean up the database. I am syncing with the BlueObelisk data repository again. There we decided to remove the density (not a element property but a compound property. I also removed the mean weight. We think it is better to provide correct data than a lot (but partly wrong) data.|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureInProgress|KAlgebra|Calculator Plasmoid|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KAlgebra|Vector support|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}
{{FeatureInProgress|Parley|Redesigned main window|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|Parley|Vocabulary Plasmoid|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|KBruch and KPercentage|Merge in 1 app|pete@pmurdoch.com|Peter Murdoch}}
{{FeatureInProgress|Kalzium|Plasmoid to access Kalzium database|cniehaus@kde.org|Carsten Niehaus}}
{{FeatureInProgress|Step|A physics simulator, move from playground to kdeedu module (it is now in kdereview)|ks.vladimir@gmail.com|Vladimir Kuznetsov}}
{{FeatureTodo|KAlgebra|Variables share between calculations|aleixpol@gmail.com|Aleix Pol}}
{{FeatureTodo|KTurtle|Export canvas as image|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Add command line|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Add a color picker|nielsslot@gmail.com|Niels Slot}}
{{FeatureTodo|Parley|Declensions|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Parley|Rewrite of practice|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KDiamond|New game, move to kdegames|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureDone|KNetWalk|Better scoring system|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureDone|KNetWalk|Add support for loading new themes|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureDone|Kollision|Move to kdereview/kdegames|p.capriotti@gmail.com|Paolo Capriotti}}
{{FeatureInProgress|KBlocks|Finish display of points and level and move to kdereview/kdegames|piacentini@kde.org}}
{{FeatureInProgress|KGoldRunner|Improved theming and animation|mikelima@cirulla.net}}
{{FeatureInProgress|KGoldRunner|Sound support and theming|mikelima@cirulla.net}}
{{FeatureInProgress|KSquares|Multiplayer support|josef}}
{{FeatureTodo|KBlocks|Add additional themes|piacentini@kde.org}}
{{FeatureTodo|KBreakout|Finish it, and move it from playground to kdegames|fela.kde@gmail.com}}
{{FeatureTodo|KDiamond|Get themes with KNewStuff|majewsky@gmx.net|Stefan Majewsky}}
{{FeatureTodo|KGGZ|Add kggzcore and kggzdmod libraries|josef}}
{{FeatureTodo|KGGZ|Add new Qt4-based core client as successor to the old KDE3-based KGGZ|josef}}
{{FeatureTodo|KGoldRunner|Also see kdegames/kgoldrunner/TODO|ianw}}
{{FeatureTodo|KGoldRunner|Hot new stuff support for themes and levels|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Startup screen|mikelima@cirulla.net}}
{{FeatureTodo|KMahjongg|Reimplement the Board Editor|piacentini@kde.org}}
{{FeatureTodo|KMines|Add pause actions|piacentini@kde.org}}
{{FeatureTodo|KNetWalk|New graphic system (port to QGraphicsView)|fela.kde@gmail.com|Fela Winkelmolen}}
{{FeatureTodo|KShisen|Port to KScoreDialog|piacentini@kde.org}}
{{FeatureTodo|Kubrick|New game, 3D OpenGL - move to playground|ianw}}
{{FeatureTodo|Kubrick|Polish up the features|ianw}}
{{FeatureTodo|Kubrick|Port to Qt4 and KDE4|ianw}}
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Gwenview|Undo system|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureDone|Okular|Better Text-To-Speech integration: speech the whole document, the current page or the selection.|pino@kde.org|Pino Toscano}}
{{FeatureDone|Okular|Encryption support for ODF generator|bradh@kde.org}}
{{FeatureInProgress|Okular|Backward direction for text search.|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|Centralized text & graphics antialias configuration.|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|EPub backend.|elylevy@cs.huji.ac.il|Ely Levy}}
{{FeatureInProgress|Okular|Improved form support (add missing types, handle the fields better).|pino@kde.org|Pino Toscano}}
{{FeatureTodo|Gwenview|Crop ratio|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|KIPI support|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|Red eye correction|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|Support for tagging with Nepomuk|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Gwenview|Thumbnail bar in view and fullscreen modes|aurelien.gateau@free.fr|Aurélien Gâteau}}
{{FeatureTodo|Okular|Support for document layers (mostly in PDF documents).|pino@kde.org|Pino Toscano}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Dragon Player|A simple Phonon-based videoplayer application|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|Make Dragon indipendent from Xine|ian.monroe@gmail.com|Ian Monroe}}
{{FeatureInProgress|Dragon Player|File Manager|David Edmunson}}
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KGet|Group-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Torrent-Support|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Transfer-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Webinterface|uwolfer@kde.org|Urs Wolfer}}
{{FeatureDone|Kopete|AIM offline messages|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureDone|Kopete|OTR Encryption support|michael_zanetti@gmx.net|Michael Zanetti}}
{{FeatureDone|Kopete|Status manager|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureInProgress|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureInProgress|Kopete|Bring back chat style and emoticon selection via knewstuff2|earthwings@gentoo.org|Dennis Nienhüser}}
{{FeatureInProgress|Kopete|ICQ 6 status icons|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureInProgress|Kopete|MSNP15 implementation for MSN|mattr@kde.org|Matt Rogers}}
{{FeatureInProgress|Kopete|Non-intrusive notification system|kedgedev@centrum.cz|Roman Jarosz}}
{{FeatureInProgress|Kopete|UPnp Support|mattr@kde.org|Matt Rogers}}
{{FeatureInProgress|Kopete|Updated contact list interface (uses Qt 4 rather than Qt 3)|mattr@kde.org|Matt Rogers}}
{{FeatureTodo|Kopete|Update Kopete to better support Decibel|kopete-devel@kde.org|Kopete Developers}}
{{FeatureTodo|KGet|Nepomuk-Integration|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Global Speedlimits|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Copy libbtcore to kdenetwork/kget|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|Kopete|GroupWise chatroom support|wstephenson@kde.org|Will Stephenson}}
{{FeatureTodo|[http://decibel.kde.org Decibel]|Decibel, a framework for real time communication services. Move from playground/pim|info@basyskom.de|Tobias Hunger}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KAddressbook|Ability to add LDAP search results to distribution lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Indication of which resource folder a contact belongs to|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Read-only view for contacts in read-only folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|copy/cut/paste context menu items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to easily create todos with reminders from emails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to open messages from search results when the reader is hidden|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better invitation update emails showing what changed|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better reminder visualization in very small events|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better, natural language search criteria names|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Clickable status columns|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Client side configurability of warnings in shared folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Colored ribbons for indication of signing and encryption status in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Configuration option for whether invitation emails are automatically deleted or not when having been acted upon|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Copy/paste and drag and drop from/to the mail composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Decryption on demand in reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Display of quota information in foldertree tooltips|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop and copy and paste support in the search result viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop from the mail reader window and mime-tree viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop of folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Editing of attachments from the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Export and import of filters|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Favorites Folder|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Folder quicksearch|m.koller@surfeu.at|Martin Koller}}
{{FeatureDone|KMail|Harmonization of actions in main and standalone mail reader windows|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|IMAP Server storage of non-standard flags|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved TNEF attachment handling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved quota warnings|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Initialize full search from quicksearch on request|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Override font and fontsize for standalone message viewers|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Per-folder identity configurability|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Recursive IMAP cache troubleshooting|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Resizable recipients area in composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for creating new mails based on received mails (Resend)|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for immediate sync of resource folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for soft line breaking|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Tab navigation through groups in the address completion|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Text snippets with shortcuts and variable expansion in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Warning about active out-of-office scripts|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|lost+found recovery of locally changed folders that lose access rights|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KNotes|Ability to print notes|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Ability to have both distribution lists and addresbook extension visible|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Aggregated reminders view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Better default resource colors|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Drag and drop of attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Faster initial loading of kolab resources|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Forwarding and delegation of invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved coloring of agenda view items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved event printing|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Merge of the attachment view in into the main page|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Merge of the free-busy and attendee views for easier scheduling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Month view scrolling, paging, mouse-wheeling|tom_t@gmx.at|Thomas Thrainer}}
{{FeatureDone|KOrganizer|More readable Kolab resource folder labels|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Redesigned incidence editor UI|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Side-by-side calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Support for by-value attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Timeline calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kleopatra|Ability to search in internal and external certificates at the same time|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kleopatra|General UI Server|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|Kleopatra|New, tabbed, mainwindow design|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureDone|KonsoleKalendar|Support "file" and "localdir" resources|winter@kde.org|Allen Winter}}
{{FeatureDone|Kontact|Config option to close despite system tray|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Harmonization of component naming in sidebar, configuration, summary view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Right-aligned component navigation toolbar|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Ubiquitous sync actions|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Column-specific whatsthis-help| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Combined search and add task widget| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Drag&Drop| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|File management (file->load)| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Managing history| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Tracking tasks by active applications| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Whatsthis-help dependant on if a task has been created| |Thorsten Stärk}}
{{FeatureInProgress|KMail|HTML Signatures|yez@familieschepers.nl|Edwin Schepers}}
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureInProgress|Kleopatra|OpenPGP support|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureInProgress|Kontact|New Planner summary; combines Appointment+To-do+SpecialDates into 1 pretty summary|winter@kde.org|Allen Winter}}
{{FeatureTodo|KAlarm|New option to specify reminder times in minutes|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Prevent multiple identical error messages accumulating for the same alarm|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remember main window show/hide options used when KAlarm closed instead of setting them in Preferences dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remove alarm daemon and do all scheduling in kalarm itself|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Replace simple repetitions by recurrence sub-repetitions to reduce confusion|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Simplification and improvements to alarm edit dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KMail|Aggregated attachment view in the mail header area of the reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Improved error messages and audit log for cryptographic operations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Ability to jump to the right day in the agenda from invitation mails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop in the free-busy view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for comments in replies to invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureTodo|Kleopatra|Konqueror and Dolphin Kleopatra plugins|marc@kdab.net|Marc Mutz (Gpg4win)}}
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application| christian_weilbach@.web.de|Christian Weilbach}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Cervisia|New context menu entry "Add to Ignore List"|christian.loose@hamburg.de|Christian Loose}}
{{FeatureDone|Lokalize|Move this application (formerly known as Kaider) from extragear|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Cervisia|A file view based on KDirModel|christian.loose@hamburg.de|Christian Loose}}
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|KBugBuster|Make it work|fabiolocati@gmail.com|Fabio Locati}}
{{FeatureInProgress|Kate|Session plasmoid|montel@kde.org|Laurent Montel}}
{{FeatureTodo|KAppTemplate|Add a PyQt template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a Plasmoid template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a Ruby template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add DBUS support|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Make a GUI for it|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|kioslave svn|Add Export/Import feature|montel@kde.org|Laurent Montel}}
|}

= kdetoys =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Okteta|bytelevel editor (successor to KHexEdit). Move from playground/utils.|kossebau@kde.org|Friedrich W. H. Kossebau}}
|}

= kdevelop =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdevplatform =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdewebdev =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

Schedules/KDE4/4.1 Feature Plan

2008-02-16T02:30:00Z

Mwoehlke: /* kdebase-workspace */ color kcm features

__NOTOC__
= Instructions =

Deadline for adding entries here for the 4.1 release is '''31 March 2008'''. 
Entries added after that date will be scheduled for the 4.2 release.

todo => not started yet 
in-progress => started, but not completed yet 
done => completed

= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|kdeui|Add KFadeWidgetEffect to easily add fading UI transitions to KDE applications|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|kross|Add QtScript support|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|Phonon KCM|More UI feedback|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|kdeui|Goya, a framework for inserting controls into itemviews in a really easy and fast way|ereslibre@kde.org|Rafael Fernández López}}
{{FeatureInProgress|kmimetypetrader/kbuildsycoca|Replace use of profilerc for ordering applications with new mimeapps.list standard|faure@kde.org|David Faure}}
{{FeatureInProgress|knewstuff|Support caching, and speed up the interface through use of Models/Views and goya|jeremy@scitools.com|Jeremy Whiting}}
{{FeatureInProgress|Phonon KCM|Handle advanced devices|kretz@kde.org|Matthias Kretz}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Akonadi|Move the Akonadi development library from kdepim.|vkrause@kde.org|Volker Krause}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Dolphin|Refactor view-action handling to a DolphinViewActionHandler to share more code with DolphinPart|faure@kde.org|David Faure}}
{{FeatureInProgress|Dolphin|Simplify selecting of files in the single-click mode (based on http://aseigo.blogspot.com/2006/04/icons.html).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Dolphin|Details-view: Allow to open folders as tree (turned off per default).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Raptor|The KDE4-Application-Menu}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Color KCM|Add 'smart setting' of extended colors|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|Color KCM|Add KDE3 scheme import|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KMagnifier|Add color blindness simulation|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|KMagnifier|Refactor color menu, re-add invert, add color-shift modes to help people with color blindness|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KSystemLog|KSystemLog, a Log Viewer Tool. Move from kde-apps|nicolas.ternisien@gmail.com}}
|}

= kdeartwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Smoke2|Move Smoke2 to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureTodo|PHP-Qt|Move PHP-Qt to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|KAlgebra|Calculator Plasmoid|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KAlgebra|Vector support|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}
{{FeatureInProgress|Parley|Redesigned main window|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|Parley|Vocabulary Plasmoid|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|KAlgebra|Variables share between calculations|aleixpol@gmail.com|Aleix Pol}}
{{FeatureTodo|KBruch and KPercentage|Merge in 1 app|pete@pmurdoch.com|Peter Murdoch}}
{{FeatureTodo|KTurtle|Export canvas as image|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|Parley|Declinations|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Parley|Rewrite of practice|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Step|A physics simulator, move from playground to kdeedu module|ks.vladimir@gmail.com|Vladimir Kuznetsov}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|KBlocks|Finish display of points and level (waiting for Qt4.4 with WidgetsOnCanvas to land in qt-copy) and move to kdereview/kdegames|piacentini@kde.org}}
{{FeatureInProgress|KGoldRunner|Improved theming and animation|mikelima@cirulla.net}}
{{FeatureInProgress|Kollision|Move to kdereview/kdegames|p.capriotti@gmail.com|Paolo Capriotti}}
{{FeatureTodo|KBreakout|Finish it, and move it from playground to kdegames|fela.kde@gmail.com}}
{{FeatureTodo|KGoldRunner|Also see kdegames/kgoldrunner/TODO|ianw}}
{{FeatureTodo|KGoldRunner|Hot new stuff support for themes and levels|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Sound support and theming|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Startup screen|mikelima@cirulla.net}}
{{FeatureTodo|KMahjongg|Reimplement the Board Editor|piacentini@kde.org}}
{{FeatureTodo|KNetWalk|Add support for loading new themes|fela.kde@gmail.com}}
{{FeatureTodo|KNetWalk|Better scoring system|fela.kde@gmail.com}}
{{FeatureTodo|KNetWalk|New graphic system|fela.kde@gmail.com}}
{{FeatureTodo|KShisen|Port to KScoreDialog|piacentini@kde.org}}
{{FeatureTodo|Kubrick|New game, 3D OpenGL - move to playground|ianw}}
{{FeatureTodo|Kubrick|Polish up the features|ianw}}
{{FeatureTodo|Kubrick|Port to Qt4 and KDE4|ianw}}
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Okular|Encryption support for ODF generator|bradh@kde.org}}
{{FeatureInProgress|Okular|Improved form support (add missing types, handle the fields better).|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|Centralized text & graphics antialias configuration.|pino@kde.org|Pino Toscano}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Dragon Player|A simple Phonon-based videoplayer application|ian.monroe@gmail.com}}
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KGet|Torrent-Support|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|Kopete|OTR Encryption support|michael_zanetti@gmx.net|Michael Zanetti}}
{{FeatureDone|KGet|Group-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Transfer-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureInProgress|KGet|Webinterface|uwolfer@kde.org|Urs Wolfer}}
{{FeatureInProgress|Kopete|Bring back chat style and emoticon selection via knewstuff2|earthwings@gentoo.org|Dennis Nienhüser}}
{{FeatureTodo|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Nepomuk-Integration|l.appelhans@gmx.de|Lukas Appelhans}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Column-specific whatsthis-help| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Combined search and add task widget| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Drag&Drop| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|File management (file->load)| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Managing history| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Tracking tasks by active applications| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Whatsthis-help dependant on if a task has been created| |Thorsten Stärk}}
{{FeatureDone|KAddressbook|Ability to add LDAP search results to distribution lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|copy/cut/paste context menu items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Indication of which resource folder a contact belongs to|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Read-only view for contacts in read-only folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kleopatra|Ability to search in internal and external certificates at the same time|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to easily create todos with reminders from emails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to open messages from search results when the reader is hidden|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better invitation update emails showing what changed|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better, natural language search criteria names|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better reminder visualization in very small events|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Clickable status columns|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Client side configurability of warnings in shared folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Colored ribbons for indication of signing and encryption status in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Configuration option for whether invitation emails are automatically deleted or not when having been acted upon|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Copy/paste and drag and drop from/to the mail composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Display of quota information in foldertree tooltips|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop and copy and paste support in the search result viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop from the mail reader window and mime-tree viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop of folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Editing of attachments from the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Export and import of filters|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Favorites Folder|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Folder quicksearch|m.koller@surfeu.at|Martin Koller}}
{{FeatureDone|KMail|Harmonization of actions in main and standalone mail reader windows|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|IMAP Server storage of non-standard flags|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved quota warnings|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved TNEF attachment handling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Initialize full search from quicksearch on request|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|lost+found recovery of locally changed folders that lose access rights|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Override font and fontsize for standalone message viewers|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Per-folder identity configurability|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Recursive IMAP cache troubleshooting|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Resizable recipients area in composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for creating new mails based on received mails (Resend)|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for immediate sync of resource folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for soft line breaking|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Tab navigation through groups in the address completion|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Text snippets with shortcuts and variable expansion in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Warning about active out-of-office scripts|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KNotes|Ability to print notes|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KonsoleKalendar|Support "file" and "localdir" resources|winter@kde.org|Allen Winter}}
{{FeatureDone|Kontact|Config option to close despite system tray|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Harmonization of component naming in sidebar, configuration, summary view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Right-aligned component navigation toolbar|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Ubiquitous sync actions|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Ability to have both distribution lists and addresbook extension visible|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Aggregated reminders view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Better default resource colors|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Faster initial loading of kolab resources|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Forwarding and delegation of invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved coloring of agenda view items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved event printing|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|More readable Kolab resource folder labels|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Side-by-side calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Support for by-value attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Timeline calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Month view scrolling, paging, mouse-wheeling|tom_t@gmx.at|Thomas Thrainer}}
{{FeatureInProgress|KMail|HTML Signatures|yez@familieschepers.nl|Edwin Schepers}}
{{FeatureInProgress|Kontact|New Planner summary; combines Appointment+To-do+SpecialDates into 1 pretty summary|winter@kde.org|Allen Winter}}
{{FeatureTodo|[http://decibel.kde.org Decibel]|Decibel, a framework for real time communication services. Move from playground/pim|info@basyskom.de|Tobias Hunger}}
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application| christian_weilbach@.web.de|Christian Weilbach}}
{{FeatureTodo|KAlarm|New option to specify reminder times in minutes|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Prevent multiple identical error messages accumulating for the same alarm|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remember main window show/hide options used when KAlarm closed instead of setting them in Preferences dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remove alarm daemon and do all scheduling in kalarm itself|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Replace simple repetitions by recurrence sub-repetitions to reduce confusion|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Simplification and improvements to alarm edit dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KMail|Aggregated attachment view in the mail header area of the reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Decryption on demand in reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Improved error messages and audit log for cryptographic operations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Ability to jump to the right day in the agenda from invitation mails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop in the free-busy view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop of attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Merge of the attachment view in into the main page|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Merge of the free-busy and attendee views for easier scheduling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Redesigned incidence editor UI|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for comments in replies to invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureTodo|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Cervisia|New context menu entry "Add to Ignore List"|christian.loose@hamburg.de|Christian Loose}}
{{FeatureDone|Lokalize|Move this application (formerly known as Kaider) from extragear|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Cervisia|A file view based on KDirModel|christian.loose@hamburg.de|Christian Loose}}
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|KAppTemplate|Add a Plasmoid template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a PyQt template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a Ruby template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add DBUS support|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Make a GUI for it|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}
|}

= kdetoys =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Okteta|bytelevel editor (successor to KHexEdit). Move from playground/utils.|kossebau@kde.org|Friedrich W. H. Kossebau}}
|}

= kdevelop =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdevplatform =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdewebdev =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

Schedules/KDE4/4.1 Feature Plan

2008-02-16T02:26:46Z

Mwoehlke: /* kdeaccessibility */ kmag features

__NOTOC__
= Instructions =

Deadline for adding entries here for the 4.1 release is '''31 March 2008'''. 
Entries added after that date will be scheduled for the 4.2 release.

todo => not started yet 
in-progress => started, but not completed yet 
done => completed

= kdelibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|kdeui|Add KFadeWidgetEffect to easily add fading UI transitions to KDE applications|kretz@kde.org|Matthias Kretz}}
{{FeatureDone|kross|Add QtScript support|mail@dipe.org|Sebastian Sauer}}
{{FeatureDone|Phonon KCM|More UI feedback|kretz@kde.org|Matthias Kretz}}
{{FeatureInProgress|kdeui|Goya, a framework for inserting controls into itemviews in a really easy and fast way|ereslibre@kde.org|Rafael Fernández López}}
{{FeatureInProgress|kmimetypetrader/kbuildsycoca|Replace use of profilerc for ordering applications with new mimeapps.list standard|faure@kde.org|David Faure}}
{{FeatureInProgress|knewstuff|Support caching, and speed up the interface through use of Models/Views and goya|jeremy@scitools.com|Jeremy Whiting}}
{{FeatureInProgress|Phonon KCM|Handle advanced devices|kretz@kde.org|Matthias Kretz}}
|}

= kdepimlibs =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Akonadi|Move the Akonadi development library from kdepim.|vkrause@kde.org|Volker Krause}}
|}

= kdebase-apps =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Dolphin|Refactor view-action handling to a DolphinViewActionHandler to share more code with DolphinPart|faure@kde.org|David Faure}}
{{FeatureInProgress|Dolphin|Simplify selecting of files in the single-click mode (based on http://aseigo.blogspot.com/2006/04/icons.html).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Dolphin|Details-view: Allow to open folders as tree (turned off per default).|peter.penz@gmx.at|Peter Penz}}
{{FeatureInProgress|Raptor|The KDE4-Application-Menu}}
|}

= kdebase-workspace =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdebase-runtime =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeaccessibility =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KMagnifier|Add color blindness simulation|mw_triad@users.sourceforge.net|Matthew Woehlke}}
{{FeatureTodo|KMagnifier|Refactor color menu, re-add invert, add color-shift modes to help people with color blindness|mw_triad@users.sourceforge.net|Matthew Woehlke}}
|}

= kdeadmin =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KSystemLog|KSystemLog, a Log Viewer Tool. Move from kde-apps|nicolas.ternisien@gmail.com}}
|}

= kdeartwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdebindings =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Smoke2|Move Smoke2 to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
{{FeatureTodo|PHP-Qt|Move PHP-Qt to kdebindings-trunk.|kde-bindings@kde.org|KDE-bindings developers}}
|}

= kdeedu =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|KAlgebra|Calculator Plasmoid|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KAlgebra|Vector support|aleixpol@gmail.com|Aleix Pol}}
{{FeatureInProgress|KEduca|Rewrite of the classic test writing/taking application|matt@milliams.com|Matt Williams}}
{{FeatureInProgress|Parley|Redesigned main window|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureInProgress|Parley|Vocabulary Plasmoid|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|KAlgebra|Variables share between calculations|aleixpol@gmail.com|Aleix Pol}}
{{FeatureTodo|KBruch and KPercentage|Merge in 1 app|pete@pmurdoch.com|Peter Murdoch}}
{{FeatureTodo|KTurtle|Export canvas as image|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|KTurtle|Optional rulers/grid for canvas units|piacentini@kde.org|Mauricio Piacentini}}
{{FeatureTodo|Parley|Declinations|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Parley|Rewrite of practice|frederik.gladhorn@kdemail.net|Frederik Gladhorn}}
{{FeatureTodo|Step|A physics simulator, move from playground to kdeedu module|ks.vladimir@gmail.com|Vladimir Kuznetsov}}
|}

= kdegames =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|KBlocks|Finish display of points and level (waiting for Qt4.4 with WidgetsOnCanvas to land in qt-copy) and move to kdereview/kdegames|piacentini@kde.org}}
{{FeatureInProgress|KGoldRunner|Improved theming and animation|mikelima@cirulla.net}}
{{FeatureInProgress|Kollision|Move to kdereview/kdegames|p.capriotti@gmail.com|Paolo Capriotti}}
{{FeatureTodo|KBreakout|Finish it, and move it from playground to kdegames|fela.kde@gmail.com}}
{{FeatureTodo|KGoldRunner|Also see kdegames/kgoldrunner/TODO|ianw}}
{{FeatureTodo|KGoldRunner|Hot new stuff support for themes and levels|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Sound support and theming|mikelima@cirulla.net}}
{{FeatureTodo|KGoldRunner|Startup screen|mikelima@cirulla.net}}
{{FeatureTodo|KMahjongg|Reimplement the Board Editor|piacentini@kde.org}}
{{FeatureTodo|KNetWalk|Add support for loading new themes|fela.kde@gmail.com}}
{{FeatureTodo|KNetWalk|Better scoring system|fela.kde@gmail.com}}
{{FeatureTodo|KNetWalk|New graphic system|fela.kde@gmail.com}}
{{FeatureTodo|KShisen|Port to KScoreDialog|piacentini@kde.org}}
{{FeatureTodo|Kubrick|New game, 3D OpenGL - move to playground|ianw}}
{{FeatureTodo|Kubrick|Polish up the features|ianw}}
{{FeatureTodo|Kubrick|Port to Qt4 and KDE4|ianw}}
|}

= kdegraphics =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureInProgress|Okular|Encryption support for ODF generator|bradh@kde.org}}
{{FeatureInProgress|Okular|Improved form support (add missing types, handle the fields better).|pino@kde.org|Pino Toscano}}
{{FeatureInProgress|Okular|Centralized text & graphics antialias configuration.|pino@kde.org|Pino Toscano}}
|}

= kdemultimedia =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Dragon Player|A simple Phonon-based videoplayer application|ian.monroe@gmail.com}}
|}

= kdenetwork =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|KGet|Torrent-Support|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|Kopete|OTR Encryption support|michael_zanetti@gmx.net|Michael Zanetti}}
{{FeatureDone|KGet|Group-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureDone|KGet|Transfer-Settings|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureInProgress|KGet|Webinterface|uwolfer@kde.org|Urs Wolfer}}
{{FeatureInProgress|Kopete|Bring back chat style and emoticon selection via knewstuff2|earthwings@gentoo.org|Dennis Nienhüser}}
{{FeatureTodo|KGet|MultiSource-Downloading|l.appelhans@gmx.de|Lukas Appelhans}}
{{FeatureTodo|KGet|Nepomuk-Integration|l.appelhans@gmx.de|Lukas Appelhans}}
|}

= kdepim =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Column-specific whatsthis-help| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Combined search and add task widget| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Drag&Drop| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|File management (file->load)| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Managing history| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Tracking tasks by active applications| |Thorsten Stärk}}
{{FeatureDone|[http://wiki.kde.org/ktimetracker ktimetracker]|Whatsthis-help dependant on if a task has been created| |Thorsten Stärk}}
{{FeatureDone|KAddressbook|Ability to add LDAP search results to distribution lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|copy/cut/paste context menu items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Indication of which resource folder a contact belongs to|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KAddressbook|Read-only view for contacts in read-only folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kleopatra|Ability to search in internal and external certificates at the same time|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to easily create todos with reminders from emails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Ability to open messages from search results when the reader is hidden|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better invitation update emails showing what changed|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better, natural language search criteria names|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Better reminder visualization in very small events|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Clickable status columns|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Client side configurability of warnings in shared folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Colored ribbons for indication of signing and encryption status in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Configuration option for whether invitation emails are automatically deleted or not when having been acted upon|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Copy/paste and drag and drop from/to the mail composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Display of quota information in foldertree tooltips|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop and copy and paste support in the search result viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop from the mail reader window and mime-tree viewer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Drag and drop of folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Editing of attachments from the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Export and import of filters|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Favorites Folder|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Folder quicksearch|m.koller@surfeu.at|Martin Koller}}
{{FeatureDone|KMail|Harmonization of actions in main and standalone mail reader windows|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|IMAP Server storage of non-standard flags|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved quota warnings|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Improved TNEF attachment handling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Initialize full search from quicksearch on request|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|lost+found recovery of locally changed folders that lose access rights|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Override font and fontsize for standalone message viewers|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Per-folder identity configurability|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Recursive IMAP cache troubleshooting|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Resizable recipients area in composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for creating new mails based on received mails (Resend)|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for immediate sync of resource folders|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Support for soft line breaking|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Tab navigation through groups in the address completion|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Text snippets with shortcuts and variable expansion in the composer|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KMail|Warning about active out-of-office scripts|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KNotes|Ability to print notes|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KonsoleKalendar|Support "file" and "localdir" resources|winter@kde.org|Allen Winter}}
{{FeatureDone|Kontact|Config option to close despite system tray|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Harmonization of component naming in sidebar, configuration, summary view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Right-aligned component navigation toolbar|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|Kontact|Ubiquitous sync actions|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Ability to have both distribution lists and addresbook extension visible|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Aggregated reminders view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Better default resource colors|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Faster initial loading of kolab resources|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Forwarding and delegation of invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved coloring of agenda view items|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Improved event printing|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|More readable Kolab resource folder labels|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Side-by-side calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Support for by-value attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Timeline calendar view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureDone|KOrganizer|Month view scrolling, paging, mouse-wheeling|tom_t@gmx.at|Thomas Thrainer}}
{{FeatureInProgress|KMail|HTML Signatures|yez@familieschepers.nl|Edwin Schepers}}
{{FeatureInProgress|Kontact|New Planner summary; combines Appointment+To-do+SpecialDates into 1 pretty summary|winter@kde.org|Allen Winter}}
{{FeatureTodo|[http://decibel.kde.org Decibel]|Decibel, a framework for real time communication services. Move from playground/pim|info@basyskom.de|Tobias Hunger}}
{{FeatureTodo|[http://kblogger.pwsp.net KBlogger]|KBlogger, a blogging application| christian_weilbach@.web.de|Christian Weilbach}}
{{FeatureTodo|KAlarm|New option to specify reminder times in minutes|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Prevent multiple identical error messages accumulating for the same alarm|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remember main window show/hide options used when KAlarm closed instead of setting them in Preferences dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Remove alarm daemon and do all scheduling in kalarm itself|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Replace simple repetitions by recurrence sub-repetitions to reduce confusion|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KAlarm|Simplification and improvements to alarm edit dialog|djarvie@kde.org|David Jarvie}}
{{FeatureTodo|KMail|Aggregated attachment view in the mail header area of the reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Decryption on demand in reader window|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KMail|Improved error messages and audit log for cryptographic operations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|Kontact|Support for Kontact wide profiles|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Ability to jump to the right day in the agenda from invitation mails|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop in the free-busy view|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Drag and drop of attachments|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Merge of the attachment view in into the main page|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Merge of the free-busy and attendee views for easier scheduling|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Redesigned incidence editor UI|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for comments in replies to invitations|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureTodo|KOrganizer|Support for extended free-busy lists|kdepim@kdab.net|Kolab Konsortium}}
{{FeatureInProgress|KPilot|Finish Keyring conduit, base conduit code and test cases, category syncing|jkasper@kde.org|Jason 'vanRijn' Kasper}}
{{FeatureTodo|KPilot|Port old conduits to new base conduit architecture and KDE4/Qt4|jkasper@kde.org|Jason 'vanRijn' Kasper}}
|}

= kdesdk =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureDone|Cervisia|New context menu entry "Add to Ignore List"|christian.loose@hamburg.de|Christian Loose}}
{{FeatureDone|Lokalize|Move this application (formerly known as Kaider) from extragear|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Cervisia|A file view based on KDirModel|christian.loose@hamburg.de|Christian Loose}}
{{FeatureInProgress|Lokalize|various Translation Memory enhancements|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureInProgress|Lokalize|XLIFF support|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|KAppTemplate|Add a Plasmoid template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a PyQt template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add a Ruby template|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Add DBUS support|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|KAppTemplate|Make a GUI for it|annma@kde.org|Anne-Marie Mahfouf}}
{{FeatureTodo|Lokalize|Kross-based scripting|shafff-at-ukr.net|Nick Shaforostoff}}
{{FeatureTodo|Lokalize|QA: glossary checklists|shafff-at-ukr.net|Nick Shaforostoff}}
|}

= kdetoys =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdeutils =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
{{FeatureTodo|Okteta|bytelevel editor (successor to KHexEdit). Move from playground/utils.|kossebau@kde.org|Friedrich W. H. Kossebau}}
|}

= kdevelop =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdevplatform =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

= kdewebdev =
{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Project !! Description !! Contact
|}

User talk:Mwoehlke

2008-01-29T17:25:47Z

Mwoehlke:

* (I'll finish writing this when I get HAL built...)
[[Getting Started/Build/HAL|Who is I?]]. Can this page be deleted, it's not changed since 5 months. --[[User:Dhaumann|Dhaumann]] 23:27, 28 January 2008 (CET)
::Hmm... I did get HAL built (was a pain IIRC), but it's been so long I don't remember all the hoops :-(. So I guess the answer is "yes", since apparently no one else cares. Deleted. --[[User:Mwoehlke|Mwoehlke]] 18:25, 29 January 2008 (CET)

Projects/Oxygen/StyleWinDec

2008-01-22T21:38:04Z

Mwoehlke: add 'enhancements' section, clean up bugs

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* The application icons on the kicker compete with K-button in taking attention. This will addle novice who isn't familiar with its appearance. I think, K-button should look as a part of kicker, not be just a simple icon, but there are maybe other solutions. See http://lh5.google.com/mmauder/R4DPHTrn_GI/AAAAAAAAAFU/fraQpZdQ0M4/krunner_disappearing.png?imgmax=912
* Plasma's button in right-top corner looks like spider web. It needs to have more respectable appearance.
* docked dockers might need a nicer frame
* Mouse handling in menus: When the mouse pointer goes below the visible selection decoration of the last item in a menu, the item does not get deselected but a click or release event will not trigger the item. The item does not get deselected until the pointer leaves the menu. The correct behavior would be to deselect the item once the pointer leaves its selection decoration and enters the bezel, as e.g. in similar KDE 3 styles (e.g. Domino). Or to trigger the item despite the pointer being outside its selection decoration, given that it is still shown as selected. As it stands, you can go to the last item in a menu, not notice that you overshoot it because it doesn't go deselected, and your click/release will do nothing, which is jarring.
* The arrow buttons (go back/go forward) don't fit at all with the others icons. They seem to have been taken from a bad GNOME icon set...
* The trash is not really usable, since it is just too hard to see if it empty or not. Furthermore, because the colors are exactly the same, it seems to be part of the hard drives (see this screenshot (http://picasaweb.google.com/mmauder/KDE400/photo#5152345685276228690) for example).
* Why are the hard drives inclined, and the usb key all vertical ? I mean, they are all volumes, so why not make them look similar ? It would be far more intuitive.
* A few comment about this screenshot (http://picasaweb.google.com/mmauder/KDE400/photo#5152342502705462338) :
** See the splashscreen window ? It has square black edges on the top coming out of the round white outline.
** The white outline suddenly disappear on the right side but continue on the left side
** Why are the bottom edges square while the top edges are round ?

== Rejected Bugs ==
* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible. We want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it 
* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.
* KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)not a style bug report to kmenu maintainer - and don't ever add things to "accepted bugs" below again - this went unnoticed because of that 
* "flat" buttons drawn same as regular buttons we may not want flat buttons - considering
* With everything around it styled nicely, having just a plain colour for selected items, e.g. in the speedbar, looks a bit disconnect from the rest of the GUI. Thus any effect that polishes this bit is welcome, such as a frame or even translucency.unfortunately that part of qt is not stylable

== Accepted Bugs ==
* Window decoration
** icons are scaled resulting in blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET) releasable
** Titlebar buttons do not 'react' when mouse clicked. Only indication when the mouse moves over them. Need a 'depressed' look/state when actually clicked like other widgets. (spstarr) 14:40, 02 December 2007 (EST) releasable
** Maximize/Restore Buttons on titlebar 'jump' and corrupt panel on redrawing. See http://rapidshare.de/files/37960220/oxygen-resize.ogg.html or http://video.tinypic.com/player.php?v=72vk3df&s=1 for example. (spstarr) 15:01, 02 December 2007 (EST) releasable
* Holes in general
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* Color problems (see also QA #3) priority
** wrong text colors: checkbox is button, should be window - groupbox is view, should be window - combobox is view, should be button (non-editable only) - tab is button, should be window
** arrows: are all button, should be view in spins, window for scrollbars - might be better fixed in KStyle?
** progress bars: should use selection for filled, button(?) for not-filled... seems to be OK but using hover for fill bg? ...not sure if button is really the color we want, but that's releasable; the hover color OTOH is likely to break with even some shipped color schemes
* progress bars still not like the artist wants priority
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable

== Accepted Enhancements ==
* Rounded corners of floatables (windows,menus dockers) should be done with alpha
* Windeco should use alpha for corners (need kwin improvements?)
* groupboxes
** make flat more homogeneous in look with normal (very short regular?)

== QA ==
This is helpful checklist to use when looking for bugs in a style:
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* [http://pastebin.ca/803298 QA color scheme]
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-12-29T03:09:58Z

Mwoehlke: cleaner and slightly more detailed list of color glitches

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* docked dockers might need a nicer frame

== Rejected Bugs ==
* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible. We want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it 
* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.
* KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)not a style bug report to kmenu maintainer - and don't ever add things to "accepted bugs" below again - this went unnoticed because of that 
* "flat" buttons drawn same as regular buttons we may not want flat buttons - considering
* With everything around it styled nicely, having just a plain colour for selected items, e.g. in the speedbar, looks a bit disconnect from the rest of the GUI. Thus any effect that polishes this bit is welcome, such as a frame or even translucency.unfortunately that part of qt is not stylable

== Accepted Bugs ==
* Window decoration
** icons are scaled resulting in blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET) releasable
** Titlebar buttons do not 'react' when mouse clicked. Only indication when the mouse moves over them. Need a 'depressed' look/state when actually clicked like other widgets. (spstarr) 14:40, 02 December 2007 (EST) releasable
** Maximize/Restore Buttons on titlebar 'jump' and corrupt panel on redrawing. See http://rapidshare.de/files/37960220/oxygen-resize.ogg.html or http://video.tinypic.com/player.php?v=72vk3df&s=1 for example. (spstarr) 15:01, 02 December 2007 (EST) releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* Holes in general
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* Color problems (see also QA #3) priority
** wrong text colors: checkbox is button, should be window - groupbox is view, should be window - combobox is view, should be button (non-editable only) - tab is button, should be window
** arrows: are all button, should be view in spins, window for scrollbars - might be better fixed in KStyle?
** progress bars: should use selection for filled, button(?) for not-filled... seems to be OK but using hover for fill bg? ...not sure if button is really the color we want, but that's releasable; the hover color OTOH is likely to break with even some shipped color schemes
* progress bars still not like the artist wants priority
* Rounded corneres of floatables (windows,menus dockers) should be done with alpha releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*tabs
**inactive tabs using black and not shade colors (hard-coded color alert) releasable
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* [http://pastebin.ca/803298 QA color scheme]
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-12-29T02:09:47Z

Mwoehlke: /* Accepted Bugs */

Projects/Oxygen/ColorSchemes

2007-12-13T16:43:57Z

Mwoehlke: new Cherry Blossom scheme, remove killed schemes

KDE4 introduces some major changes in color schemes. Here you will find an overview of some new color-related features, as well as a preview of the new color schemes.

This should probably go somewhere better (like, "the documentation"?). For now techbase (with winterz' "highly-unofficial" permission) is being abused as a dumping ground for screenshots, in order to try to solicit feedback from kde-artists.

= Colors =
* Inactive Text
** Used for text that should be subdued (e.g. comments, extended file information)
* Active Text
** Used for text that wants to draw attention to itself, or is "active" (e.g. hovered links)
* Link Text
* Visited Text
** This, and the previous one, should be obvious :-).
* Negative Text
** Used for errors, etc.
* Neutral Text
** Used for text that wishes to set itself apart, but does not belong to the other roles (e.g. warnings, secure content).
* Focus Decoration
** Used to indicate what control will respond to keyboard input. For example, default buttons use this, input widgets use this when they have focus, etc.
* Hover Decoration
** Used to draw 'hover' (mouseover) effects.

The "Common Colors" set allows setting the most important colors in one place. Note that "Selection Inactive Text" means "Inactive Text" belonging to the "Selection" set, and is not related to inactive effects in any way. Also note that currently no auto-calculation is performed, so you need to go to each set to specify the alternate background color.

= Effects =
KDE4 introduces "state effects"; three effects that can be applied to inactive windows, and disabled widgets.

* Intensity
** Allows adjusting the overall brightness. 'shade' adjusts luma by an absolute amount (-1.0 to 1.0), 'darken' and 'lighten' adjust by a percentage, where negative percentages are allowed (e.g. -50% results in new_luma = 1.5 * old_luma).
* Color
** Allows adjusting the overall color, either by multiplying the chrome ('desaturate' - again, negative values are allowed, which results in increasing the chroma), mixing with another color ('fade'), or tinting with another color ('tint'). Tinting tends to change hue/chroma much more rapidly while preserving luma.
* Contrast
** Allows adjusting only foreground colors, so that e.g. text becomes less prominent. The effects are 'fade' and 'tint'; the background color is used as the target.

NOTE: Inactive effects cause additional window repaints that some people may find annoying, or may cause performance problems on older machines.

= Options =
* Apply inactive window color effects
** The built-in color schemes define inactive effects. If you do not wish to use them, this provides an easy way to turn them off. (default=off)
* Inactive selection changes color
** KDE4 strives to join the rest of the world by using a different color for selection in widgets that do not have focus, enhancing Usability. Due to performance concerns, the default is off until these can be addressed, hopefully in Qt 4.5, but if you have a good computer, you are strongly encouraged to try enabling this.
** Because inactive window effects incur the performance penalty anyway, checking 'apply inactive window color effects' will enable this option if it has not been manually clicked (similarly, unchecking said option will disable this one in the same situation).
* Shade sorted column in lists
** This is currently not implemented by listviews :-(.
* Contrast
** This controls the strength of 3D effects.

= Schemes =
The author ([[User:mwoehlke|Matthew Woehlke]], also the creator of all of these color schemes, with varying levels of inspiration or blatant copying) apologizes for the marketing spiel you are about to be subjected to if you read this section ;-).

== Blue Deep ==
[[Image:Blue-deep.png|thumbnail|Blue Deep]]
Rich blues, vibrant yet soothing, threaten to pull you into the watery depths of this scheme. This is a port of the KDE3 scheme Dark Blue.

== Cherry Blossom ==
[[Image:SchemeCherryBlossom.png|thumbnail|Cherry Blossom]]
Soft, light pinks touched with green bring a gentle, eastern feel to this scheme reminiscent of the famous tree.

== Chrome ==
[[Image:SchemeChrome.png|thumbnail|Chrome]]
Bright, shiny gray with just a touch of blue, combined with vibrant blue accents, conjures the feel of polished metal, as well as memories of Keramik and Plastik schemes from KDE3.

== Desert ==
[[Image:SchemeDesert.png|thumbnail|Desert]]
Soft shades of sand are accented by rich red. This scheme is a port of the KDE3 scheme by the same name.

== Evening Lilac ==
[[Image:SchemeEveningLilac.png|thumbnail|Evening Lilac]]
Dusty gray-purple with touches of green bring to mind a lilac bush on a warm summer night.

== Highland Mist ==
[[Image:SchemeHighland-mist.png|thumbnail|Highland Mist]]
Pale shades of green with a touch of blue accents evoke images of grass-covered hills shrouded in fog.

== Honeycomb ==
[[Image:SchemeHoneycomb.png|thumbnail|Honeycomb]]
Soft shades of gray touched by yellow mix with honey-colored highlights to give an impression of bees, or perhaps BeOS.

== Midnight Meadow ==
[[Image:SchemeMidnightMeadow.png|thumbnail|Midnight Meadow]]
Dark shades of green shimmer with unearthly light in this scheme inspired by the glow of a sea of lush green grass in the deep of night.

== Norway ==
[[Image:SchemeNorway.png|thumbnail|Norway]]
Kudos if you can figure out the reference here. Due to questionable content, it will not be posted ;-). This scheme added at the request of Eike Hein, and inspired by [http://members.shaw.ca/lucx/ Charamel for Firefox]

== Obsidian Coast ==
[[Image:SchemeObsidianCoast.png|thumbnail|Obsidian Coast]]
Inspired by movies of dark waves breaking against tall, black cliffs, this scheme (a dark version of Whitewater) is perfect for those that love a sense of foreboding, or just the rich, natural look of volcanic glass.

== Steel ==
[[Image:SchemeSteel.png|thumbnail|Steel]]
Warm gray, subtle gold, and striking cyan come together in a warm industrial tribute to classic skyscrapers in the late afternoon sun.

== Stone Orchid ==
[[Image:SchemeStoneOrchid.png|thumbnail|Stone Orchid]]
Rich gray with a hint of floral meets soft cyan and vibrant royal-purple accents in this scheme inspired by orchids, and KDE3's Solaris.

== Terra ==
[[Image:SchemeTerra.png|thumbnail|Terra]]
Gray mingled with green joins blue accents in this outdoor scheme inspired by grass and rocks against a clear sky.

== White Peach ==
[[Image:SchemeWhitePeach.png|thumbnail|White Peach]]
Inspired by a juice label, this scheme brings vibrant, light peachy tones reminiscent of juice by the same name, and welds it with floral green accents.

== Whitewater ==
[[Image:Whitewater.png|thumbnail|Whitewater]]
Calling to mind the river canyons of Colorado, this neutral scheme features a solid earthy/rocky gray base with blue accents.

== Wonton Soup ==
[[Image:SchemeWontonSoup.png|thumbnail|Wonton Soup]]
Created from the KDE3-era wallpaper of the same name, this scheme was made by [[User:mwoehlke|Matthew Woehlke]], who uses (and has used, for about two years) it as his KDE3 scheme.

== Zion ==
[[Image:SchemeZion.png|thumbnail|Zion]]
Reminiscent of the computers in the fictional city of the same name from the [http://en.wikipedia.org/wiki/The_Matrix_(series) Matrix trilogy], this scheme features mainly black foreground elements on a starkly white background. It is included in kdeaccessibility and is intended to aid users with visual difficulties.

== Zion (Reversed) ==
[[Image:SchemeZionReversed.png|thumbnail|Zion (Reversed)]]
An inverse of the Zion scheme, this provides white-on-black elements, again maximizing contrast.

File:SchemeCherryBlossom.png

2007-12-13T16:37:41Z

Mwoehlke:

Schedules/KDE4/4.0 Release Beta Goals

2007-12-13T03:09:32Z

Mwoehlke: /* Color configuration */

This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.

You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:release-team@kde.org release-team@kde.org]

=== Plasma ===
*''current state:'' showstopper
*''contact:'' [mailto:aseigo@kde.org Aaron J. Seigo]
*''goal:'' A basic panel is there; current work is to flesh it out into a more capable panel system. System tray and taskbar both need work as does a desktop containment with legacy support for the Desktop folder.
*''howto help:'' help is always welcome; there are a number of people contributing to plasma already but more help can make things go faster. If you want to help, join the irc channel #plasma or mail to [mailto:panel-devel@kde.org panel-devel@kde.org]
*''expected time of arrival:'' unknown, but close

=== Color configuration ===
*''current state:'' color list broken
*''contact:'' [[User:mwoehlke| Matthew Woehlke]]
*''goals:''
** fix size bug in color list (QTableView bug?) priority
** sort schemes in list cosmetic
** don't save options in schemes cosmetic
** confirmation when discarding changes to working scheme, [http://bugs.kde.org/show_bug.cgi?id=152883 bug 152883] releasable
*''howto help:'' Polish and Usability review welcome.

=== Oxygen style ===
*''current state:'' releaseable if really needed
*''contact:'' [[User:mwoehlke| Matthew Woehlke]], [mailto:cbr@boemann.dkCasper Boemann], #oxygen
*''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
*''howto help:'' ask on #oxygen
*''expected time of arrival:'' unknown

=== Konqueror ===
*''current state:'' showstopper
*''contact:'' [mailto:faure@kde.org David Faure]
*''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
*''howto help:''
**Help is most welcome. [mailto:kfm-devel@kde.org kfm-devel@kde.org] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
**Bigger tasks include:
***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
***finishing the integration of the dolphin part for file management.
***open bugs are on [http://bugs.kde.org/buglist.cgi?product=konqueror&version=4.0&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&cmdtype=doit| this Bugzilla page]
*''expected time of arrival:'' november (if we leave out the sidebar changes), else december.

=== Dolphin ===
*''current state:'' some showstoppers
*''contact:'' [mailto:peter.penz@gmx.at Peter Penz]
*''goal:'' I think Dolphin is in a quite acceptable state now. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
*''howto help:''
**I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape.
***I'm not sure about the state of Nepomuk. Currently the performance is too slow for sorting items by tags or rating. It would be possible to use an internal cache in Dolphin for this, but this would only reduce the time from O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
*''expected time of arrival:'' Unknown, dfaure is working on http://bugs.kde.org/show_bug.cgi?id=152902 and there also is http://bugs.kde.org/show_bug.cgi?id=152904 which is not dolphin related, but it affects this app.

=== Kate ===
*''current state:'' some missing features & bugs, but usable
*''contact:'' [mailto:kwrite-devel@kde.org Kate Team]
*''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
*''howto help:''
** <s>fix printing</s> Fixed by Anders, 2007-10-20
** <s>fix shortcut settings</s> Fixed by mstocker
** <s>rendering bugfixes</s> seems to be ok (fixed everything I know), by mstocker
** config saving bugfixes
** testing
*''expected time of arrival:'' unknown, but very close

=== Printing ===
*''current state:'' no showstopper any more
*''contact:'' [mailto:huntedhacker@tiscali.co.uk Alex Merry] (randomguy3)
*''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
*help needed: API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui. Okular has support for printing PS files directly, although this will only work on *NIX platforms (it requires lpr or cups). Basically, all that is left is test, test, test.
*''howto help:'' heavy testing required, send reports of problems to [mailto:kde-print-devel@kde.org kde-print-devel@kde.org] mailing list, preferably with a patch, or report problems on [http://bugs.kde.org Bugzilla].
*''expected time of arrival:'' All was done by 26th Nov.

=== Sound ===
*''current state:'' ready
*''contact:'' [mailto:kretz@kde.org Matthias Kretz]
*''goal:''
*# no showstopper: do some more automatic tests that all sound devices work as expected
*''howto help:'' Mailinglists: [mailto:phonon-backends@kde.org phonon-backends@kde.org] or [mailto:kde-multimedia@kde.org kde-multimedia@kde.org], IRC: #phonon ping Vir
**Local audio playback is working quite OK, but there are some issues that are still open:
*** https://bugzilla.redhat.com/show_bug.cgi?id=284171 (should be fixed with libc 2.7)
*** Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
*** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif (this will hopefully get fixed with libxine 1.2)

=== Co-installability ===
*''current state:'' A state where packagers can work around the rest. 
*''contact:'' k-c-d
*''goal:'' Distros should be able to coinstall packages in the same prefix in a way that makes it possible to use kde3 apps on a kde4 desktop or to use kde4 apps on a kde3 desktop.
*''how to help''
** fix kinfocenter && khelpcenter in some magic way
*''details:''
** kde3libs, kde4libs, kdepimlibs, kde4base(apps, runtime, workspace) should be coinstallable => kde3 apps in a kde4 desktop
** AND
** kde3libs, kde3base, kde4libs, kdepimlibs, kde4base-runtime should be coinstallable => kde4 apps in a kde3 desktop
** And only those with the -devel stuff stripped out.
*''list of conflicting files:'' [[Projects/KDE3_KDE4_coinstallability| KDE3/KDE4 coinstallability]]
*''NOTE''
** This does not cover apps like konsole, konqueror, kmail, ... There can of course only be one of each application installed in same prefix. It is only about the runtime parts of the other desktop.
*''expected time of arrival:'' Very soon

Projects/Oxygen/ColorSchemes

2007-12-11T16:41:16Z

Mwoehlke: Blue Deep - port of Dark Blue (name is not the same, my bad)

KDE4 introduces some major changes in color schemes. Here you will find an overview of some new color-related features, as well as a preview of the new color schemes.

This should probably go somewhere better (like, "the documentation"?). For now techbase (with winterz' "highly-unofficial" permission) is being abused as a dumping ground for screenshots, in order to try to solicit feedback from kde-artists.

= Colors =
* Inactive Text
** Used for text that should be subdued (e.g. comments, extended file information)
* Active Text
** Used for text that wants to draw attention to itself, or is "active" (e.g. hovered links)
* Link Text
* Visited Text
** This, and the previous one, should be obvious :-).
* Negative Text
** Used for errors, etc.
* Neutral Text
** Used for text that wishes to set itself apart, but does not belong to the other roles (e.g. warnings, secure content).
* Focus Decoration
** Used to indicate what control will respond to keyboard input. For example, default buttons use this, input widgets use this when they have focus, etc.
* Hover Decoration
** Used to draw 'hover' (mouseover) effects.

The "Common Colors" set allows setting the most important colors in one place. Note that "Selection Inactive Text" means "Inactive Text" belonging to the "Selection" set, and is not related to inactive effects in any way. Also note that currently no auto-calculation is performed, so you need to go to each set to specify the alternate background color.

= Effects =
KDE4 introduces "state effects"; three effects that can be applied to inactive windows, and disabled widgets.

* Intensity
** Allows adjusting the overall brightness. 'shade' adjusts luma by an absolute amount (-1.0 to 1.0), 'darken' and 'lighten' adjust by a percentage, where negative percentages are allowed (e.g. -50% results in new_luma = 1.5 * old_luma).
* Color
** Allows adjusting the overall color, either by multiplying the chrome ('desaturate' - again, negative values are allowed, which results in increasing the chroma), mixing with another color ('fade'), or tinting with another color ('tint'). Tinting tends to change hue/chroma much more rapidly while preserving luma.
* Contrast
** Allows adjusting only foreground colors, so that e.g. text becomes less prominent. The effects are 'fade' and 'tint'; the background color is used as the target.

NOTE: Inactive effects cause additional window repaints that some people may find annoying, or may cause performance problems on older machines.

= Options =
* Apply inactive window color effects
** The built-in color schemes define inactive effects. If you do not wish to use them, this provides an easy way to turn them off. (default=off)
* Inactive selection changes color
** KDE4 strives to join the rest of the world by using a different color for selection in widgets that do not have focus, enhancing Usability. Due to performance concerns, the default is off until these can be addressed, hopefully in Qt 4.5, but if you have a good computer, you are strongly encouraged to try enabling this.
** Because inactive window effects incur the performance penalty anyway, checking 'apply inactive window color effects' will enable this option if it has not been manually clicked (similarly, unchecking said option will disable this one in the same situation).
* Shade sorted column in lists
** This is currently not implemented by listviews :-(.
* Contrast
** This controls the strength of 3D effects.

= Schemes =
The author ([[User:mwoehlke|Matthew Woehlke]], also the creator of all of these color schemes, with varying levels of inspiration or blatant copying) apologizes for the marketing spiel you are about to be subjected to if you read this section ;-).

== Blue Deep ==
[[Image:Blue-deep.png|thumbnail|Blue Deep]]
Rich blues, vibrant yet soothing, threaten to pull you into the watery depths of this scheme. This is a port of the KDE3 scheme Dark Blue.

== Chrome ==
[[Image:SchemeChrome.png|thumbnail|Chrome]]
Bright, shiny gray with just a touch of blue, combined with vibrant blue accents, conjures the feel of polished metal, as well as memories of Keramik and Plastik schemes from KDE3.

== Desert ==
[[Image:SchemeDesert.png|thumbnail|Desert]]
Soft shades of sand are accented by rich red. This scheme is a port of the KDE3 scheme by the same name.

== Desert Night ==
[[Image:DesertNight.png|thumbnail|Desert Night]]
Rich orange reflects moonlit dunes, while striking blue reflects the sky above, in this echo of a desert at night. (Brought to you by the same dubious idea that produced Water Orchid. Also likely to go.)

== Evening Lilac ==
[[Image:SchemeEveningLilac.png|thumbnail|Evening Lilac]]
Dusty gray-purple with touches of green bring to mind a lilac bush on a warm summer night.

== Highland Mist ==
[[Image:SchemeHighland-mist.png|thumbnail|Highland Mist]]
Pale shades of green with a touch of blue accents evoke images of grass-covered hills shrouded in fog.

== Honeycomb ==
[[Image:SchemeHoneycomb.png|thumbnail|Honeycomb]]
Soft shades of gray touched by yellow mix with honey-colored highlights to give an impression of bees, or perhaps BeOS.

== Midnight Meadow ==
[[Image:SchemeMidnightMeadow.png|thumbnail|Midnight Meadow]]
Dark shades of green shimmer with unearthly light in this scheme inspired by the glow of a sea of lush green grass in the deep of night.

== Norway ==
[[Image:SchemeNorway.png|thumbnail|Norway]]
Kudos if you can figure out the reference here. Due to questionable content, it will not be posted ;-). This scheme added at the request of Eike Hein, and inspired by [http://members.shaw.ca/lucx/ Charamel for Firefox]

== Obsidian Coast ==
[[Image:SchemeObsidianCoast.png|thumbnail|Obsidian Coast]]
Inspired by movies of dark waves breaking against tall, black cliffs, this scheme (a dark version of Whitewater) is perfect for those that love a sense of foreboding, or just the rich, natural look of volcanic glass.

== Rose ==
[[Image:SchemeRose.png|thumbnail|Rose]]
Soft shades of red invoke feelings of muted passion.

== Steel ==
[[Image:SchemeSteel.png|thumbnail|Steel]]
Warm gray, subtle gold, and striking cyan come together in a warm industrial tribute to classic skyscrapers in the late afternoon sun.

== Stone Orchid ==
[[Image:SchemeStoneOrchid.png|thumbnail|Stone Orchid]]
Rich gray with a hint of floral meets soft cyan and vibrant royal-purple accents in this scheme inspired by orchids, and KDE3's Solaris.

== Terra ==
[[Image:SchemeTerra.png|thumbnail|Terra]]
Gray mingled with green joins blue accents in this outdoor scheme inspired by grass and rocks against a clear sky.

== Water Orchid ==
[[Image:SchemeWaterOrchid.png|thumbnail|Water Orchid]]
Attempting to bring to mind a beautiful purple flower against a turquoise background, this scheme instead looks like a mad candy store. (Here we see the peril of making color schemes from wallpapers, and a Microsoft one at that. This one is almost certain to get the axe before 4.0.)

== White Peach ==
[[Image:SchemeWhitePeach.png|thumbnail|White Peach]]
Inspired by a juice label, this scheme brings pale-but-bright peachy reminiscent of juice by the same name and welds it with floral green accents.

== Whitewater ==
[[Image:Whitewater.png|thumbnail|Whitewater]]
Calling to mind the river canyons of Colorado, this neutral scheme features a deep, earthy/rocky gray base with blue accents.

== Wonton Soup ==
[[Image:SchemeWontonSoup.png|thumbnail|Wonton Soup]]
Created from the KDE3-era wallpaper of the same name, this scheme was made by [[User:mwoehlke|Matthew Woehlke]], who uses (and has used, for about two years) it as his KDE3 scheme.

== Zion ==
[[Image:SchemeZion.png|thumbnail|Zion]]
Reminiscent of the computers in the fictional city of the same name from the [http://en.wikipedia.org/wiki/The_Matrix_(series) Matrix trilogy], this scheme features mainly black foreground elements on a starkly white background. It is included in kdeaccessibility and is intended to aid users with visual difficulties.

== Zion (Reversed) ==
[[Image:SchemeZionReversed.png|thumbnail|Zion (Reversed)]]
An inverse of the Zion scheme, this provides white-on-black elements, again maximizing contrast.

Projects/Oxygen/ColorSchemes

2007-12-11T03:17:17Z

Mwoehlke: add scheme thumbnails

KDE4 introduces some major changes in color schemes. Here you will find an overview of some new color-related features, as well as a preview of the new color schemes.

This should probably go somewhere better (like, "the documentation"?). For now techbase (with winterz' "highly-unofficial" permission) is being abused as a dumping ground for screenshots, in order to try to solicit feedback from kde-artists.

= Colors =
* Inactive Text
** Used for text that should be subdued (e.g. comments, extended file information)
* Active Text
** Used for text that wants to draw attention to itself, or is "active" (e.g. hovered links)
* Link Text
* Visited Text
** This, and the previous one, should be obvious :-).
* Negative Text
** Used for errors, etc.
* Neutral Text
** Used for text that wishes to set itself apart, but does not belong to the other roles (e.g. warnings, secure content).
* Focus Decoration
** Used to indicate what control will respond to keyboard input. For example, default buttons use this, input widgets use this when they have focus, etc.
* Hover Decoration
** Used to draw 'hover' (mouseover) effects.

The "Common Colors" set allows setting the most important colors in one place. Note that "Selection Inactive Text" means "Inactive Text" belonging to the "Selection" set, and is not related to inactive effects in any way. Also note that currently no auto-calculation is performed, so you need to go to each set to specify the alternate background color.

= Effects =
KDE4 introduces "state effects"; three effects that can be applied to inactive windows, and disabled widgets.

* Intensity
** Allows adjusting the overall brightness. 'shade' adjusts luma by an absolute amount (-1.0 to 1.0), 'darken' and 'lighten' adjust by a percentage, where negative percentages are allowed (e.g. -50% results in new_luma = 1.5 * old_luma).
* Color
** Allows adjusting the overall color, either by multiplying the chrome ('desaturate' - again, negative values are allowed, which results in increasing the chroma), mixing with another color ('fade'), or tinting with another color ('tint'). Tinting tends to change hue/chroma much more rapidly while preserving luma.
* Contrast
** Allows adjusting only foreground colors, so that e.g. text becomes less prominent. The effects are 'fade' and 'tint'; the background color is used as the target.

NOTE: Inactive effects cause additional window repaints that some people may find annoying, or may cause performance problems on older machines.

= Options =
* Apply inactive window color effects
** The built-in color schemes define inactive effects. If you do not wish to use them, this provides an easy way to turn them off. (default=off)
* Inactive selection changes color
** KDE4 strives to join the rest of the world by using a different color for selection in widgets that do not have focus, enhancing Usability. Due to performance concerns, the default is off until these can be addressed, hopefully in Qt 4.5, but if you have a good computer, you are strongly encouraged to try enabling this.
** Because inactive window effects incur the performance penalty anyway, checking 'apply inactive window color effects' will enable this option if it has not been manually clicked (similarly, unchecking said option will disable this one in the same situation).
* Shade sorted column in lists
** This is currently not implemented by listviews :-(.
* Contrast
** This controls the strength of 3D effects.

= Schemes =
The author ([[User:mwoehlke|Matthew Woehlke]], also the creator of all of these color schemes, with varying levels of inspiration or blatant copying) apologizes for the marketing spiel you are about to be subjected to if you read this section ;-).

== Blue Deep ==
[[Image:Blue-deep.png|thumbnail|Blue Deep]]
Rich blues, vibrant yet soothing, threaten to pull you into the watery depths of this scheme. This is a port of the KDE3 scheme by the same name.

== Chrome ==
[[Image:SchemeChrome.png|thumbnail|Chrome]]
Bright, shiny gray with just a touch of blue, combined with vibrant blue accents, conjures the feel of polished metal, as well as memories of Keramik and Plastik schemes from KDE3.

== Desert ==
[[Image:SchemeDesert.png|thumbnail|Desert]]
Soft shades of sand are accented by rich red. This scheme is a port of the KDE3 scheme by the same name.

== Desert Night ==
[[Image:DesertNight.png|thumbnail|Desert Night]]
Rich orange reflects moonlit dunes, while striking blue reflects the sky above, in this echo of a desert at night. (Brought to you by the same dubious idea that produced Water Orchid. Also likely to go.)

== Evening Lilac ==
[[Image:SchemeEveningLilac.png|thumbnail|Evening Lilac]]
Dusty gray-purple with touches of green bring to mind a lilac bush on a warm summer night.

== Highland Mist ==
[[Image:SchemeHighland-mist.png|thumbnail|Highland Mist]]
Pale shades of green with a touch of blue accents evoke images of grass-covered hills shrouded in fog.

== Honeycomb ==
[[Image:SchemeHoneycomb.png|thumbnail|Honeycomb]]
Soft shades of gray touched by yellow mix with honey-colored highlights to give an impression of bees, or perhaps BeOS.

== Midnight Meadow ==
[[Image:SchemeMidnightMeadow.png|thumbnail|Midnight Meadow]]
Dark shades of green shimmer with unearthly light in this scheme inspired by the glow of a sea of lush green grass in the deep of night.

== Norway ==
[[Image:SchemeNorway.png|thumbnail|Norway]]
Kudos if you can figure out the reference here. Due to questionable content, it will not be posted ;-). This scheme added at the request of Eike Hein, and inspired by [http://members.shaw.ca/lucx/ Charamel for Firefox]

== Obsidian Coast ==
[[Image:SchemeObsidianCoast.png|thumbnail|Obsidian Coast]]
Inspired by movies of dark waves breaking against tall, black cliffs, this scheme (a dark version of Whitewater) is perfect for those that love a sense of foreboding, or just the rich, natural look of volcanic glass.

== Rose ==
[[Image:SchemeRose.png|thumbnail|Rose]]
Soft shades of red invoke feelings of muted passion.

== Steel ==
[[Image:SchemeSteel.png|thumbnail|Steel]]
Warm gray, subtle gold, and striking cyan come together in a warm industrial tribute to classic skyscrapers in the late afternoon sun.

== Stone Orchid ==
[[Image:SchemeStoneOrchid.png|thumbnail|Stone Orchid]]
Rich gray with a hint of floral meets soft cyan and vibrant royal-purple accents in this scheme inspired by orchids, and KDE3's Solaris.

== Terra ==
[[Image:SchemeTerra.png|thumbnail|Terra]]
Gray mingled with green joins blue accents in this outdoor scheme inspired by grass and rocks against a clear sky.

== Water Orchid ==
[[Image:SchemeWaterOrchid.png|thumbnail|Water Orchid]]
Attempting to bring to mind a beautiful purple flower against a turquoise background, this scheme instead looks like a mad candy store. (Here we see the peril of making color schemes from wallpapers, and a Microsoft one at that. This one is almost certain to get the axe before 4.0.)

== White Peach ==
[[Image:SchemeWhitePeach.png|thumbnail|White Peach]]
Inspired by a juice label, this scheme brings pale-but-bright peachy reminiscent of juice by the same name and welds it with floral green accents.

== Whitewater ==
[[Image:Whitewater.png|thumbnail|Whitewater]]
Calling to mind the river canyons of Colorado, this neutral scheme features a deep, earthy/rocky gray base with blue accents.

== Wonton Soup ==
[[Image:SchemeWontonSoup.png|thumbnail|Wonton Soup]]
Created from the KDE3-era wallpaper of the same name, this scheme was made by [[User:mwoehlke|Matthew Woehlke]], who uses (and has used, for about two years) it as his KDE3 scheme.

== Zion ==
[[Image:SchemeZion.png|thumbnail|Zion]]
Reminiscent of the computers in the fictional city of the same name from the [http://en.wikipedia.org/wiki/The_Matrix_(series) Matrix trilogy], this scheme features mainly black foreground elements on a starkly white background. It is included in kdeaccessibility and is intended to aid users with visual difficulties.

== Zion (Reversed) ==
[[Image:SchemeZionReversed.png|thumbnail|Zion (Reversed)]]
An inverse of the Zion scheme, this provides white-on-black elements, again maximizing contrast.

File:SchemeDesert.png

2007-12-11T03:15:24Z

Mwoehlke:

File:SchemeEveningLilac.png

2007-12-11T03:14:22Z

Mwoehlke:

File:SchemeHighland-mist.png

2007-12-11T03:13:07Z

Mwoehlke:

File:SchemeHoneycomb.png

2007-12-11T03:10:39Z

Mwoehlke:

File:SchemeMidnightMeadow.png

2007-12-11T03:09:57Z

Mwoehlke:

File:SchemeNorway.png

2007-12-11T03:09:13Z

Mwoehlke:

File:Whitewater.png

2007-12-11T03:08:22Z

Mwoehlke:

File:SchemeObsidianCoast.png

2007-12-11T03:07:50Z

Mwoehlke:

File:SchemeSteel.png

2007-12-11T03:06:28Z

Mwoehlke:

File:SchemeStoneOrchid.png

2007-12-11T03:05:27Z

Mwoehlke:

File:SchemeTerra.png

2007-12-11T03:04:34Z

Mwoehlke:

File:SchemeWhitePeach.png

2007-12-11T03:02:51Z

Mwoehlke:

File:SchemeWontonSoup.png

2007-12-11T02:59:27Z

Mwoehlke:

File:SchemeZion.png

2007-12-11T02:56:57Z

Mwoehlke:

File:SchemeZionReversed.png

2007-12-11T02:55:42Z

Mwoehlke:

File:SchemeChrome.png

2007-12-11T02:43:22Z

Mwoehlke:

File:Blue-deep.png

2007-12-11T02:39:53Z

Mwoehlke:

Projects/Oxygen/ColorSchemes

2007-12-11T02:22:00Z

Mwoehlke: Create article

KDE4 introduces some major changes in color schemes. Here you will find an overview of some new color-related features, as well as a preview of the new color schemes.

This should probably go somewhere better (like, "the documentation"?). For now techbase (with winterz' "highly-unofficial" permission) is being abused as a dumping ground for screenshots, in order to try to solicit feedback from kde-artists.

= Colors =
* Inactive Text
** Used for text that should be subdued (e.g. comments, extended file information)
* Active Text
** Used for text that wants to draw attention to itself, or is "active" (e.g. hovered links)
* Link Text
* Visited Text
** This, and the previous one, should be obvious :-).
* Negative Text
** Used for errors, etc.
* Neutral Text
** Used for text that wishes to set itself apart, but does not belong to the other roles (e.g. warnings, secure content).
* Focus Decoration
** Used to indicate what control will respond to keyboard input. For example, default buttons use this, input widgets use this when they have focus, etc.
* Hover Decoration
** Used to draw 'hover' (mouseover) effects.

The "Common Colors" set allows setting the most important colors in one place. Note that "Selection Inactive Text" means "Inactive Text" belonging to the "Selection" set, and is not related to inactive effects in any way. Also note that currently no auto-calculation is performed, so you need to go to each set to specify the alternate background color.

= Effects =
KDE4 introduces "state effects"; three effects that can be applied to inactive windows, and disabled widgets.

* Intensity
** Allows adjusting the overall brightness. 'shade' adjusts luma by an absolute amount (-1.0 to 1.0), 'darken' and 'lighten' adjust by a percentage, where negative percentages are allowed (e.g. -50% results in new_luma = 1.5 * old_luma).
* Color
** Allows adjusting the overall color, either by multiplying the chrome ('desaturate' - again, negative values are allowed, which results in increasing the chroma), mixing with another color ('fade'), or tinting with another color ('tint'). Tinting tends to change hue/chroma much more rapidly while preserving luma.
* Contrast
** Allows adjusting only foreground colors, so that e.g. text becomes less prominent. The effects are 'fade' and 'tint'; the background color is used as the target.

NOTE: Inactive effects cause additional window repaints that some people may find annoying, or may cause performance problems on older machines.

= Options =
* Apply inactive window color effects
** The built-in color schemes define inactive effects. If you do not wish to use them, this provides an easy way to turn them off. (default=off)
* Inactive selection changes color
** KDE4 strives to join the rest of the world by using a different color for selection in widgets that do not have focus, enhancing Usability. Due to performance concerns, the default is off until these can be addressed, hopefully in Qt 4.5, but if you have a good computer, you are strongly encouraged to try enabling this.
** Because inactive window effects incur the performance penalty anyway, checking 'apply inactive window color effects' will enable this option if it has not been manually clicked (similarly, unchecking said option will disable this one in the same situation).
* Shade sorted column in lists
** This is currently not implemented by listviews :-(.
* Contrast
** This controls the strength of 3D effects.

= Schemes =
The author ([[User:mwoehlke|Matthew Woehlke]], also the creator of all of these color schemes, with varying levels of inspiration or blatant copying) apologizes for the marketing spiel you are about to be subjected to if you read this section ;-).

Screenshots are coming.

== Blue Deep ==
Rich blues, vibrant yet soothing, threaten to pull you into the watery depths of this scheme. This is a port of the KDE3 scheme by the same name.
== Chrome ==
Bright, shiny gray with just a touch of blue, combined with vibrant blue accents, conjures the feel of polished metal, as well as memories of Keramik and Plastik schemes from KDE3.
== Desert ==
Soft shades of sand are accented by rich red. This scheme is a port of the KDE3 scheme by the same name.
== Desert Night ==
Rich orange reflects moonlit dunes, while striking blue reflects the sky above, in this echo of a desert at night. (Brought to you by the same dubious idea that produced Water Orchid. Also likely to go.)
== Evening Lilac ==
Dusty gray-purple with touches of green bring to mind a lilac bush on a warm summer night.
== Highland Mist ==
Pale shades of green with a touch of blue accents evoke images of grass-covered hills shrouded in fog.
== Honeycomb ==
Soft shades of gray touched by yellow mix with honey-colored highlights to give an impression of bees, or perhaps BeOS.
== Midnight Meadow ==
Dark shades of green shimmer with unearthly light in this scheme inspired by the glow of a sea of lush green grass in the deep of night.
== Norway ==
Kudos if you can figure out the reference here. Due to questionable content, it will not be posted ;-). This scheme added at the request of Eike Hein, and inspired by [http://members.shaw.ca/lucx/ Charamel for Firefox]
== Obsidian Coast ==
Inspired by movies of dark waves breaking against tall, black cliffs, this scheme (a dark version of Whitewater) is perfect for those that love a sense of foreboding, or just the rich, natural look of volcanic glass.
== Rose ==
Soft shades of red invoke feelings of muted passion.
== Steel ==
Warm gray, subtle gold, and striking cyan come together in a warm industrial tribute to classic skyscrapers in the late afternoon sun.
== Stone Orchid ==
Rich gray with a hint of floral meets soft cyan and vibrant royal-purple accents in this scheme inspired by orchids, and KDE3's Solaris.
== Terra ==
Gray mingled with green joins blue accents in this outdoor scheme inspired by grass and rocks against a clear sky.
== Water Orchid ==
Attempting to bring to mind a beautiful purple flower against a turquoise background, this scheme instead looks like a mad candy store. (Here we see the peril of making color schemes from wallpapers, and a Microsoft one at that. This one is almost certain to get the axe before 4.0.)
== White Peach ==
Inspired by a juice label, this scheme brings pale-but-bright peachy reminiscent of juice by the same name and welds it with floral green accents.
== Whitewater ==
Calling to mind the river canyons of Colorado, this neutral scheme features a deep, earthy/rocky gray base with blue accents.
== Wonton Soup ==
Created from the KDE3-era wallpaper of the same name, this scheme was made by [[User:mwoehlke|Matthew Woehlke]], who uses (and has used, for about two years) it as his KDE3 scheme.
== Zion ==
Reminiscent of the computers in the fictional city of the same name from the [http://en.wikipedia.org/wiki/The_Matrix_(series) Matrix trilogy], this scheme features mainly black foreground elements on a starkly white background. It is included in kdeaccessibility and is intended to aid users with visual difficulties.
== Zion (Reversed) ==
An inverse of the Zion scheme, this provides white-on-black elements, again maximizing contrast.

Schedules/KDE4/4.0 Release Beta Goals

2007-12-07T19:42:20Z

Mwoehlke: Color configuration - is now releasable

This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.

You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:release-team@kde.org release-team@kde.org]

=== Plasma ===
*''current state:'' showstopper
*''contact:'' [mailto:aseigo@kde.org Aaron J. Seigo]
*''goal:'' A basic panel is there; current work is to flesh it out into a more capable panel system. System tray and taskbar both need work as does a desktop containment with legacy support for the Desktop folder.
*''howto help:'' help is always welcome; there are a number of people contributing to plasma already but more help can make things go faster. If you want to help, join the irc channel #plasma or mail to [mailto:panel-devel@kde.org panel-devel@kde.org]
*''expected time of arrival:'' unknown, but close

=== Color configuration ===
*''current state:'' releasable
*''contact:'' [[User:mwoehlke| Matthew Woehlke]]
*''goals:''
** sort schemes in list cosmetic
** don't save options in schemes cosmetic
** confirmation when discarding changes to working scheme, [http://bugs.kde.org/show_bug.cgi?id=152883 bug 152883] releasable
*''howto help:'' Polish and Usability review welcome.

=== Oxygen style ===
*''current state:'' releaseable if really needed
*''contact:'' [[User:mwoehlke| Matthew Woehlke]], [mailto:cbr@boemann.dkCasper Boemann], #oxygen
*''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
*''howto help:'' ask on #oxygen
*''expected time of arrival:'' unknown

=== Konqueror ===
*''current state:'' showstopper
*''contact:'' [mailto:faure@kde.org David Faure]
*''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
*''howto help:''
**Help is most welcome. [mailto:kfm-devel@kde.org kfm-devel@kde.org] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
**Bigger tasks include:
***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
***finishing the integration of the dolphin part for file management.
***open bugs are on [http://bugs.kde.org/buglist.cgi?product=konqueror&version=4.0&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&cmdtype=doit| this Bugzilla page]
*''expected time of arrival:'' november (if we leave out the sidebar changes), else december.

=== Dolphin ===
*''current state:'' some showstoppers
*''contact:'' [mailto:peter.penz@gmx.at Peter Penz]
*''goal:'' I think Dolphin is in a quite acceptable state now. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
*''howto help:''
**I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape.
***I'm not sure about the state of Nepomuk. Currently the performance is too slow for sorting items by tags or rating. It would be possible to use an internal cache in Dolphin for this, but this would only reduce the time from O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
*''expected time of arrival:'' Unknown, dfaure is working on http://bugs.kde.org/show_bug.cgi?id=152902 and there also is http://bugs.kde.org/show_bug.cgi?id=152904 which is not dolphin related, but it affects this app.

=== Kate ===
*''current state:'' some missing features & bugs, but usable
*''contact:'' [mailto:kwrite-devel@kde.org Kate Team]
*''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
*''howto help:''
** <s>fix printing</s> Fixed by Anders, 2007-10-20
** <s>fix shortcut settings</s> Fixed by mstocker
** <s>rendering bugfixes</s> seems to be ok (fixed everything I know), by mstocker
** config saving bugfixes
** testing
*''expected time of arrival:'' unknown, but very close

=== Printing ===
*''current state:'' no showstopper any more
*''contact:'' [mailto:huntedhacker@tiscali.co.uk Alex Merry] (randomguy3)
*''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
*help needed: API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui. Okular has support for printing PS files directly, although this will only work on *NIX platforms (it requires lpr or cups). Basically, all that is left is test, test, test.
*''howto help:'' heavy testing required, send reports of problems to [mailto:kde-print-devel@kde.org kde-print-devel@kde.org] mailing list, preferably with a patch, or report problems on [http://bugs.kde.org Bugzilla].
*''expected time of arrival:'' All was done by 26th Nov.

=== Sound ===
*''current state:'' ready
*''contact:'' [mailto:kretz@kde.org Matthias Kretz]
*''goal:''
*# no showstopper: do some more automatic tests that all sound devices work as expected
*''howto help:'' Mailinglists: [mailto:phonon-backends@kde.org phonon-backends@kde.org] or [mailto:kde-multimedia@kde.org kde-multimedia@kde.org], IRC: #phonon ping Vir
**Local audio playback is working quite OK, but there are some issues that are still open:
*** https://bugzilla.redhat.com/show_bug.cgi?id=284171 (should be fixed with libc 2.7)
*** Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
*** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif (this will hopefully get fixed with libxine 1.2)

=== Co-installability ===
*''current state:'' A state where packagers can work around the rest. 
*''contact:'' k-c-d
*''goal:'' Distros should be able to coinstall packages in the same prefix in a way that makes it possible to use kde3 apps on a kde4 desktop or to use kde4 apps on a kde3 desktop.
*''how to help''
** fix kinfocenter && khelpcenter in some magic way
*''details:''
** kde3libs, kde4libs, kdepimlibs, kde4base(apps, runtime, workspace) should be coinstallable => kde3 apps in a kde4 desktop
** AND
** kde3libs, kde3base, kde4libs, kdepimlibs, kde4base-runtime should be coinstallable => kde4 apps in a kde3 desktop
** And only those with the -devel stuff stripped out.
*''list of conflicting files:'' [[Projects/KDE3_KDE4_coinstallability| KDE3/KDE4 coinstallability]]
*''NOTE''
** This does not cover apps like konsole, konqueror, kmail, ... There can of course only be one of each application installed in same prefix. It is only about the runtime parts of the other desktop.
*''expected time of arrival:'' Very soon

Projects/Oxygen/StyleWinDec

2007-12-04T16:36:37Z

Mwoehlke: link to QA color scheme

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* When the tabbar has many tabs, so that not all of them can be shown at once, arrow buttons are drawn to navigate to the other tabs. These arrows are painted incorrectly, see [http://bugs.kde.org/show_bug.cgi?id=152327 this bug report].
* An icon set on a [Q]PushButton is not drawn respecting QAbstractButton::abstractSize() - look at the user pic selector in kcmshell4 kdm->Users.
* On a menu, it is not possible to see which menu is actually active.
::See [http://bugs.kde.org/show_bug.cgi?id=152123 this bug report]
* In Beta4, it seems that the WinDeco doesn't yet get the color scheme from the kcm color module. i.e., changing the active/inactive window colors doesn't seem to actually work.
* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible 
: what about altering the size hints so the whole widget moves down? Trouble is we want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it - believe me - I've spent several hours on this.
* The ok and cancel buttons on dialogs (so called 'control buttons') don't have the same width. Not a style problem 
* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.
* Window decoration scales the menu icons down resulting in the icons blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET)
* Dockers; the title is positioned too far to the left and it runs into the rounded-border
* Window titlebar buttons do not 'react' when mouse clicked. Only indication when the mouse moves over them. Need a 'depressed' look/state when actually clicked like other widgets. (spstarr) 14:40, 02 December 2007 (EST)
* Maximize/Restore Buttons on task bar 'jump' and corrupt panel on redrawing. See http://rapidshare.de/files/37960220/oxygen-resize.ogg.html or http://video.tinypic.com/player.php?v=72vk3df&s=1 for example. (spstarr) 15:01, 02 December 2007 (EST)
* Disabled menu items are drawn with the disabled background colour and probably should not, to keep the menu looking consistent. To reproduce, open a new Konsole and look at the disabled Scrollback->Find Next menu item. [[User:Bille]]

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** small glitches in filling inactive tabs priority
** tab bar edge should extend full length of widget releasable
* Dockers
** frame when floating should have rounded corners releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* "flat" buttons drawn same as regular buttons releasable
* Holes in general
** need bigger margins so shadow/glow are not lost?
** fix non-rounded corners when filling (at least) lineedits priority
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* QToolBox not drawn like artists want releasable
* need to audit color role use (see QA #3) priority
* Reverse layout is broken
** listview,tablevies paint the frame in LTR place Qt issue 137304 releasable
* progress bars still not like the artist wants priority
* menus not done releasable
** KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)
* windeco
** corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable
* Groupboxes
** does not report a minimum size that allows it to show the text on the box. I.e. a groupbox with no contents, the groupbox-title is clipped. releasable
* Buttons on KNewStuff download dialog do not appear

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* [http://pastebin.ca/803298 QA color scheme]
* tabs, in all directions
* no gray space between scrollbar and the text area it controls.
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Schedules/KDE4/4.0 Release Beta Goals

2007-11-22T00:30:26Z

Mwoehlke: /* Color configuration */

This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.

You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:release-team@kde.org release-team@kde.org]

=== Plasma ===
*''current state:'' showstopper
*''contact:'' [mailto:aseigo@kde.org Aaron J. Seigo]
*''goal:'' A basic panel is there; current work is to flesh it out into a more capable panel system. System tray and taskbar both need work as does a desktop containment with legacy support for the Desktop folder.
*''howto help:'' help is always welcome; there are a number of people contributing to plasma already but more help can make things go faster. If you want to help, join the irc channel #plasma or mail to [mailto:panel-devel@kde.org panel-devel@kde.org]
*''expected time of arrival:'' By Nov 18

=== Color configuration ===
*''current state:'' very, very close
*''contact:'' [[User:mwoehlke| Matthew Woehlke]]
*''goals:''
** missing current and default pseudo-schemes important
** effects not configurable now working
*''howto help:'' Polish, Usability review, and help with the pseudo-schemes would be nice.
*''expected time of arrival:'' unknown?

=== Oxygen style ===
*''current state:'' showstopper
*''contact:'' [[User:mwoehlke| Matthew Woehlke]], [mailto:cbr@boemann.dkCasper Boemann], #oxygen
*''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
*''howto help:'' ask on #oxygen, help needed for the corners of the windec.
*''expected time of arrival:'' end of October or early November

=== Konqueror ===
*''current state:'' showstopper
*''contact:'' [mailto:faure@kde.org David Faure]
*''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
*''howto help:''
**Help is most welcome. [mailto:kfm-devel@kde.org kfm-devel@kde.org] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
**Bigger tasks include:
***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
***finishing the integration of the dolphin part for file management.
*''expected time of arrival:'' november (if we leave out the sidebar changes), else december.

=== Dolphin ===
*''current state:'' no showstopper anymore
*''contact:'' [mailto:peter.penz@gmx.at Peter Penz]
*''goal:'' I think Dolphin is in a quite acceptable state now and I'll have a lot of time during the next week to fix the most serious bugs. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
*''howto help:''
**I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape. Maybe David can comment whether some help is needed in this area (I've set David to CC).
***I'm not sure about the state of Nepomuk. Currently the performance is too slow for sorting items by tags or rating. It would be possible to use an internal cache in Dolphin for this, but this would only reduce the time from O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
*''expected time of arrival:'' My plan is that all serious bugs get closed until the end of September. No known showstoppers are left :-)

=== Kate ===
*''current state:'' some missing features & bugs, but usable
*''contact:'' [mailto:kwrite-devel@kde.org Kate Team]
*''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
*''howto help:''
** <s>fix printing</s> Fixed by Anders, 2007-10-20
** <s>fix shortcut settings</s> Fixed by mstocker
** <s>rendering bugfixes</s> seems to be ok (fixed everything I know), by mstocker
** config saving bugfixes
** testing
*''expected time of arrival:''

=== Printing ===
*''current state:'' showstopper, but only for certain applications
*''contact:'' [mailto:huntedhacker@tiscali.co.uk Alex Merry] (randomguy3)
*''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
*help needed: Most of the necessary API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui. We currently have no way to print pdf or ps files directly (as used by Okular, for example), but this is being worked on by John Layt. Almost complete.
*''howto help:'' heavy testing required, send reports of problems to [mailto:kde-print-devel@kde.org kde-print-devel@kde.org] mailing list, preferably with a patch, or report problems on [http://bugs.kde.org Bugzilla].
*''expected time of arrival:'' Printing in final few apps (Okular in particular) hopefully by 19th Nov.

=== Sound ===
*''current state:'' showstopper
*''contact:'' [mailto:kretz@kde.org Matthias Kretz]
*''goal:''
*# no showstopper: do some more automatic tests that all sound devices work as expected
*# done.
*# done.
*#Playing short ogg files only plays the start of the sound (which can be nothing at times). This is a showstopper for notification sounds. Apparently xine's ogg demuxer discards some data if the last read buffer is too small.
*''howto help:'' I certainly want help. But I don't know how I could label any of the tasks as small because for most things you need quite a good overview... :-( Mailinglists: [mailto:phonon-backends@kde.org phonon-backends@kde.org] or [mailto:kde-multimedia@kde.org kde-multimedia@kde.org], IRC: #phonon ping Vir
**Local audio playback is working quite OK, but there are some issues that are still open:
*** https://bugzilla.redhat.com/show_bug.cgi?id=284171
*** Sound hardware/ALSA setup
**** There's a report that outputting to a dmix: ALSA device using a hardware mixing capable soundcard made mixing not work at all (don't ask me why), so the ALSA device name choosing algorithm might need to become a bit smarter. I think the safest bet for now is to use the default:CARD=... device string, but with that you can only choose what card you want, not what device on that card (I don't have hardware where this would make a difference, so no idea if it's needed).
**** Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
*** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif
*''expected time of arrival:'' one week + the time it takes for libxine to release a version with the bugfix.

=== Co-installability ===
*''current state:'' A state where packagers can work around the rest. 
*''contact:'' k-c-d
*''goal:'' Distros should be able to coinstall packages in the same prefix in a way that makes it possible to use kde3 apps on a kde4 desktop or to use kde4 apps on a kde3 desktop.
*''how to help''
** fix kinfocenter && khelpcenter in some magic way
*''details:''
** kde3libs, kde4libs, kdepimlibs, kde4base(apps, runtime, workspace) should be coinstallable => kde3 apps in a kde4 desktop
** AND
** kde3libs, kde3base, kde4libs, kdepimlibs, kde4base-runtime should be coinstallable => kde4 apps in a kde3 desktop
** And only those with the -devel stuff stripped out.
*''list of conflicting files:'' [[Projects/KDE3_KDE4_coinstallability| KDE3/KDE4 coinstallability]]
*''NOTE''
** This does not cover apps like konsole, konqueror, kmail, ... There can of course only be one of each application installed in same prefix. It is only about the runtime parts of the other desktop.
*''expected time of arrival:'' Very soon

Projects/Oxygen/StyleWinDec

2007-11-19T23:00:30Z

Mwoehlke: konqeror bug fixed (sans bug now in main list), thanks fredrikh!

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* When the tabbar has many tabs, so that not all of them can be shown at once, arrow buttons are drawn to navigate to the other tabs. These arrows are painted incorrectly, see [http://bugs.kde.org/show_bug.cgi?id=152327 this bug report].

* An icon set on a [Q]PushButton is not drawn respecting QAbstractButton::abstractSize() - look at the user pic selector in kcmshell4 kdm->Users.

* On a menu, it is not possible to see which menu is actually active.
::See [http://bugs.kde.org/show_bug.cgi?id=152123 this bug report]
* In Beta4, it seems that the WinDeco doesn't yet get the color scheme from the kcm color module. i.e., changing the active/inactive window colors doesn't seem to actually work.

* The bouncing icon (the launch feedback) is black. This was also happening with drag-n-drop icons from Plasma Applet Browser, but is now fixed.

* Dockers; the title is positioned too far to the left and it runs into the rounded-border

* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible 
: what about altering the size hints so the whole widget moves down? Trouble is we want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it - believe me - I've spent several hours on this.

* The ok and cancel buttons on dialogs (so called 'control buttons') don't have the same width. Not a style problem 

* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.

* Window decoration scales the menu icons down resulting in the icons blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET)

* Qt Dockwidgets that have vertical titles (i.e. the titlebar is on the left instead of the top) don't have properly rotated text

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** small glitches in filling inactive tabs priority
** tab bar edge should extend full length of widget releasable
* Dockers
** frame when docked can be overwritten releasable
** frame when floating should have rounded corners releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* "flat" buttons drawn same as regular buttons releasable
* KLineEdit
** stylesheets ruin the look. Aseigo says to wait for qt fix showstopper
* Holes in general
** need bigger margins so shadow/glow are not lost?
** fix non-rounded corners when filling (at least) lineedits priority
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* QToolBox not drawn showstopper
* need to audit color role use (see QA #3) showstopper
* Reverse layout is broken
** listview,tablevies paint the frame in LTR place Qt issue 137304 releasable
* progress bars still not like the artist wants priority
* menus not done releasable
** KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)
* windeco
** corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable
* Groupboxes
** does not report a minimum size that allows it to show the text on the box. I.e. a groupbox with no contents, the groupbox-title is clipped. releasable
** metrics for checkable groupboxes broken (see discussion for screenshot) priority
* Buttons on KNewStuff download dialog do not appear

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* tabs, in all directions
* no gray space between scrollbar and the text area it controls.
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-11-19T20:52:44Z

Mwoehlke: /* Known Bugs */

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* When the tabbar has many tabs, so that not all of them can be shown at once, arrow buttons are drawn to navigate to the other tabs. These arrows are painted incorrectly, see [http://bugs.kde.org/show_bug.cgi?id=152327 this bug report].

* The tabbar is shown above the contents in konqueror(!). Can't see how that's possible; doesn't happen with plastique style so it has to be oxygen... (David Faure)

* An icon set on a [Q]PushButton is not drawn respecting QAbstractButton::abstractSize() - look at the user pic selector in kcmshell4 kdm->Users.

* On a menu, it is not possible to see which menu is actually active.
::See [http://bugs.kde.org/show_bug.cgi?id=152123 this bug report]
* In Beta4, it seems that the WinDeco doesn't yet get the color scheme from the kcm color module. i.e., changing the active/inactive window colors doesn't seem to actually work.

* The bouncing icon (the launch feedback) is black. This was also happening with drag-n-drop icons from Plasma Applet Browser, but is now fixed.

* Dockers; the title is positioned too far to the left and it runs into the rounded-border

* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible 
: what about altering the size hints so the whole widget moves down? Trouble is we want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it - believe me - I've spent several hours on this.

* The ok and cancel buttons on dialogs (so called 'control buttons') don't have the same width. Not a style problem 

* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.

* Window decoration scales the menu icons down resulting in the icons blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET)

* Qt Dockwidgets that have vertical titles (i.e. the titlebar is on the left instead of the top) don't have properly rotated text

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** small glitches in filling inactive tabs priority
** tab bar edge should extend full length of widget releasable
* Dockers
** frame when docked can be overwritten releasable
** frame when floating should have rounded corners releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* "flat" buttons drawn same as regular buttons releasable
* KLineEdit
** stylesheets ruin the look. Aseigo says to wait for qt fix showstopper
* Holes in general
** need bigger margins so shadow/glow are not lost?
** fix non-rounded corners when filling (at least) lineedits priority
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* QToolBox not drawn showstopper
* need to audit color role use (see QA #3) showstopper
* Reverse layout is broken
** listview,tablevies paint the frame in LTR place Qt issue 137304 releasable
* progress bars still not like the artist wants priority
* menus not done releasable
** KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)
* windeco
** corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable
* Groupboxes
** does not report a minimum size that allows it to show the text on the box. I.e. a groupbox with no contents, the groupbox-title is clipped. releasable
** metrics for checkable groupboxes broken (see discussion for screenshot) priority
* Buttons on KNewStuff download dialog do not appear

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* tabs, in all directions
* no gray space between scrollbar and the text area it controls.
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-11-01T18:40:19Z

Mwoehlke: confirm 'flat buttons' bug

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* The bouncing icon (the launch feedback) is black. This was also happening with drag-n-drop icons from Plasma Applet Browser, but is now fixed.

* Dockers; the title is positioned too far to the left and it runs into the rounded-border

* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible 
: what about altering the size hints so the whole widget moves down? Trouble is we want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it - believe me - I've spent several hours on this.

* The ok and cancel buttons on dialogs (so called 'control buttons') don't have the same width. Not a style problem 

* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.

* Window decoration scales the menu icons down resulting in the icons blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET)

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** small glitches in filling inactive tabs priority
* Dockers
** frame when docked can be overwritten releasable
** frame when floating should have rounded corners releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* "flat" buttons drawn same as regular buttons releasable
* KLineEdit
** stylesheets ruin the look. Aseigo says to wait for qt fix showstopper
* Holes in general
** need bigger margins so shadow/glow are not lost?
** fix non-rounded corners when filling (at least) lineedits priority
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* QToolBox not drawn showstopper
* need to audit color role use (see QA #3) showstopper
* Reverse layout is broken
** listview,tablevies paint the frame in LTR place Qt issue 137304 releasable
* progress bars still not like the artist wants priority
* menus not done releasable
** KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)
* windeco
** corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable
* Groupboxes
** does not report a minimum size that allows it to show the text on the box. I.e. a groupbox with no contents, the groupbox-title is clipped. releasable
** metrics for checkable groupboxes broken (see discussion for screenshot) priority
* Buttons on KNewStuff download dialog do not appear

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* tabs, in all directions
* no gray space between scrollbar and the text area it controls.
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-11-01T15:23:15Z

Mwoehlke: undo unauthorized changes, new notes about changing this page

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Visitors ==
Add new bugs to [[#Incoming_New_Bugs|Incoming New Bugs]], and we (the developers) will move it down and prioritize.

Note: we may move invalid bugs may be moved to the discussion page, along with a reason why they won't be fixed [by us].

DO NOT EDIT OTHER SECTIONS WITHOUT PERMISSION. This page has now been protected due to unauthorized edits. If you need to leave a comment anonymously, do it on the discussion page and/or talk to us on #oxygen.

== Incoming New Bugs ==
* The bouncing icon (the launch feedback) is black. This was also happening with drag-n-drop icons from Plasma Applet Browser, but is now fixed.

* Dockers; the title is positioned too far to the left and it runs into the rounded-border

* In (double) spinboxes the font is positioned one pixel too high. Lowering it one makes it baseline-aligned with labels in front. Unfortunately not possible 
: what about altering the size hints so the whole widget moves down? Trouble is we want them to be the same size as editable comboboxes and lineedits and buttons so those line up. The 1px wrong placement of text is a qt weirdness that gives visual bugs when we try to work around it - believe me - I've spent several hours on this.

* The ok and cancel buttons on dialogs (so called 'control buttons') don't have the same width. Not a style problem 

* Centered group titles pose several problems. Left align group titles instead. See Discussion for more details.

* Window decoration scales the menu icons down resulting in the icons blurring. Interestingly in the kwindecoration kcmshell the preview shows the 16x16/mimetypes/unknown.png icon at its correct 16x16 size, but as soon as the use the deco for real, it starts blurring them. (This is also true for KDE4's Plastik deco). [[User:Djmdave|Djmdave]] 22:26, 28 October 2007 (CET)

* QPushButton::setFlat() is not honored

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** small glitches in filling inactive tabs priority
* Dockers
** frame when docked can be overwritten releasable
** frame when floating should have rounded corners releasable
* KHTML integration
** khtml makes illegal assumptions about buttons. Awaits patch review by Maxim showstopper
* KLineEdit
** stylesheets ruin the look. Aseigo says to wait for qt fix showstopper
* Holes in general
** need bigger margins so shadow/glow are not lost?
** fix non-rounded corners when filling (at least) lineedits priority
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* QToolBox not drawn showstopper
* need to audit color role use (see QA #3) showstopper
* Reverse layout is broken
** listview,tablevies paint the frame in LTR place Qt issue 137304 releasable
* progress bars still not like the artist wants priority
* menus not done releasable
** KMenu::addTitle() adds a widget action to display a title in a popup menu. This is not specific to Oxygen, but the widget it creates could use some polishing. (to see this, right click any icon in the system tray)
* windeco
** corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
*headers in tables
**not really done - but the plain color look is acceptable for now releasable
* checkboxes in Q3ListView (Kontact-ToDo) are broken releasable
* Groupboxes
** does not report a minimum size that allows it to show the text on the box. I.e. a groupbox with no contents, the groupbox-title is clipped. releasable
** metrics for checkable groupboxes broken (see discussion for screenshot) priority
* Buttons on KNewStuff download dialog do not appear

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* tabs, in all directions
* no gray space between scrollbar and the text area it controls.
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are
* no obvious glitches in uidemo

[[Category:Artwork]][[Category:Oxygen]]

Projects/Oxygen/StyleWinDec

2007-11-01T15:10:06Z

Mwoehlke: Protected "Projects/Oxygen/StyleWinDec": no more anonymous changes, we have unauthorized edits happening... [edit=autoconfirmed:move=autoconfirmed]

Schedules/KDE4/4.0 Release Beta Goals

2007-10-31T21:10:17Z

Mwoehlke: /* Color configuration */

This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.

You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:release-team@kde.org release-team@kde.org]

=== Plasma ===
*''current state:'' showstopper
*''contact:'' [mailto:aseigo@kde.org Aaron J. Seigo]
*''goal:'' A basic panel is there; current work is to flesh it out into a more capable panel system. System tray and taskbar both need work as does a desktop containment with legacy support for the Desktop folder.
*''howto help:'' help is always welcome; there are a number of people contributing to plasma already but more help can make things go faster. If you want to help, join the irc channel #plasma or mail to [mailto:panel-devel@kde.org panel-devel@kde.org]
*''expected time of arrival:'' By the rc's.

=== Color configuration ===
*''current state:'' nearly there
*''contact:'' [[User:mwoehlke| Matthew Woehlke]]
*''goals:''
** missing current and default pseudo-schemes important
** multiple schemes of same name (e.g. in $KDEDIR and $KDEHOME) cause duplicate entries, should only show first one in config search path important
** effects not configurable priority, but could live without
*''howto help:'' We have this pretty well under control. Polish, Usability review, possibly help with the pseudo-schemes and/or effects tab would be nice, but if we have to, we can probably live with it as-is.
*''expected time of arrival:'' early November, but usable as-is.

=== Oxygen style ===
*''current state:'' showstopper
*''contact:'' [[User:mwoehlke| Matthew Woehlke]], [mailto:cbr@boemann.dkCasper Boemann], #oxygen
*''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
*''howto help:'' ask on #oxygen, help needed for the corners of the windec.
*''expected time of arrival:'' end of October or early November

=== Konqueror ===
*''current state:'' showstopper
*''contact:'' [mailto:faure@kde.org David Faure]
*''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
*''howto help:''
**Help is most welcome. [mailto:kfm-devel@kde.org kfm-devel@kde.org] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
**Bigger tasks include:
***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
***finishing the integration of the dolphin part for file management.
*''expected time of arrival:'' november (if we leave out the sidebar changes), else december.

=== Dolphin ===
*''current state:'' no showstopper anymore
*''contact:'' [mailto:peter.penz@gmx.at Peter Penz]
*''goal:'' I think Dolphin is in a quite acceptable state now and I'll have a lot of time during the next week to fix the most serious bugs. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
*''howto help:''
**I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape. Maybe David can comment whether some help is needed in this area (I've set David to CC).
***I'm not sure about the state of Nepomuk. Currently the performance is too slow for sorting items by tags or rating. It would be possible to use an internal cache in Dolphin for this, but this would only reduce the time from O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
*''expected time of arrival:'' My plan is that all serious bugs get closed until the end of September. No known showstoppers are left :-)

=== Kate ===
*''current state:'' some missing features & bugs, but usable
*''contact:'' [mailto:kwrite-devel@kde.org Kate Team]
*''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
*''howto help:''
** <s>fix printing</s> Fixed by Anders, 2007-10-20
** <s>fix shortcut settings</s> Fixed by mstocker
** <s>rendering bugfixes</s> seems to be ok (fixed everything I know), by mstocker
** config saving bugfixes
** testing
*''expected time of arrival:''

=== Printing ===
*''current state:'' showstopper
*''contact:'' [mailto:huntedhacker@tiscali.co.uk Alex Merry] (randomguy3)
*''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
*help needed: Most of the necessary API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui. We currently have no way to print pdf or ps files directly (as used by Okular, for example), but this is being worked on by John Layt.
*''howto help:'' send e-mail to the [mailto:kde-print-devel@kde.org kde-print-devel@kde.org] mailing list, or email the maintainer of a program volunteering to port its printing support.
*''expected time of arrival:'' API by 3rd Nov?

=== Sound ===
*''current state:'' showstopper
*''contact:'' [mailto:kretz@kde.org Matthias Kretz]
*''goal:''
*# no showstopper: do some more automatic tests that all sound devices work as expected
*# done.
*#usable KMix
*#Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a showstopper for notification sounds. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
*''howto help:'' I certainly want help. But I don't know how I could label any of the tasks as small because for most things you need quite a good overview... :-( Mailinglists: [mailto:phonon-backends@kde.org phonon-backends@kde.org] or [mailto:kde-multimedia@kde.org kde-multimedia@kde.org], IRC: #phonon ping Vir
**Local audio playback is working quite OK, but there are some issues that are still open:
*** https://bugzilla.redhat.com/show_bug.cgi?id=284171
*** Sound hardware/ALSA setup
**** There's a report that outputting to a dmix: ALSA device using a hardware mixing capable soundcard made mixing not work at all (don't ask me why), so the ALSA device name choosing algorithm might need to become a bit smarter. I think the safest bet for now is to use the default:CARD=... device string, but with that you can only choose what card you want, not what device on that card (I don't have hardware where this would make a difference, so no idea if it's needed).
**** Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
*** kmix is not in a good state (yet). Also it still does not react on plugged/unplugged soundcard or new/removed software control.
*** Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a big problem for notifications. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
*** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif
*''expected time of arrival:'' For 4. I have no idea because I don't know the cause. 3. is a bit out of my scope, though I might come up with a test app that does what I want soon...

=== Co-installability ===
*''current state:'' A state where packagers can work around the rest. 
*''contact:'' k-c-d
*''goal:'' Distros should be able to coinstall packages in the same prefix in a way that makes it possible to use kde3 apps on a kde4 desktop or to use kde4 apps on a kde3 desktop.
*''how to help''
** fix kinfocenter && khelpcenter in some magic way
*''details:''
** kde3libs, kde4libs, kdepimlibs, kde4base(apps, runtime, workspace) should be coinstallable => kde3 apps in a kde4 desktop
** AND
** kde3libs, kde3base, kde4libs, kdepimlibs, kde4base-runtime should be coinstallable => kde4 apps in a kde3 desktop
** And only those with the -devel stuff stripped out.
*''NOTE''
** This does not cover apps like konsole, konqueror, kmail, ... There can of course only be one of each application installed in same prefix. It is only about the runtime parts of the other desktop.
*''expected time of arrival:'' Very soon

Projects/Oxygen/StyleWinDec

2007-10-25T17:09:00Z

Mwoehlke: new groupbox bug

Projects/Oxygen/StyleWinDec

2007-10-25T16:43:48Z

Mwoehlke: scrollbars are fixed

Schedules/KDE4/4.0 Release Beta Goals

2007-10-25T16:41:54Z

Mwoehlke: color kcm, oxygen updates

This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.

You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:release-team@kde.org release-team@kde.org]

=== Plasma ===
*''current state:'' showstopper
*''contact:'' [mailto:aseigo@kde.org Aaron J. Seigo]
*''goal:'' panels need to be finished, application launch menu
*''howto help:'' help is always welcome; there are a number of people contributing to plasma already, however. Unfortunately most are either working on peripheral pieces or find the core pieces too difficult. If you want to help, join the irc channel #plasma or mail to [mailto:panel-devel@kde.org panel-devel@kde.org]
*''expected time of arrival:'' The plan is for a panel and menu to arrive in the next couple of weeks. Polishing will take a bit longer.

=== Color configuration ===
*''current state:'' nearly there
*''contact:'' [[User:mwoehlke| Matthew Woehlke]]
*''goals:''
** missing current and default pseudo-schemes important
** effects not configurable priority, but could live without
*''howto help:'' We have this pretty well under control. Polish, Usability review, possibly help with the pseudo-schemes and/or effects tab would be nice, but if we have to, we can probably live with it as-is.
*''expected time of arrival:'' early November, but usable as-is.

=== Oxygen style ===
*''current state:'' showstopper
*''contact:'' [[User:mwoehlke| Matthew Woehlke]], [mailto:cbr@boemann.dkCasper Boemann], #oxygen
*''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
*''howto help:'' ask on #oxygen, help needed for the corners of the windec.
*''expected time of arrival:'' end of October or early November

=== Konqueror ===
*''current state:'' showstopper
*''contact:'' [mailto:faure@kde.org David Faure]
*''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
*''howto help:''
**Help is most welcome. [mailto:kfm-devel@kde.org kfm-devel@kde.org] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
**Bigger tasks include:
***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
***finishing the integration of the dolphin part for file management.
*''expected time of arrival:'' november (if we leave out the sidebar changes), else december.

=== Dolphin ===
*''current state:'' no showstopper anymore
*''contact:'' [mailto:peter.penz@gmx.at Peter Penz]
*''goal:'' I think Dolphin is in a quite acceptable state now and I'll have a lot of time during the next week to fix the most serious bugs. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
*''howto help:''
**I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape. Maybe David can comment whether some help is needed in this area (I've set David to CC).
***I'm not sure about the state of Nepomuk. Currently the performance is too slow for sorting items by tags or rating. It would be possible to use an internal cache in Dolphin for this, but this would only reduce the time from O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
*''expected time of arrival:'' My plan is that all serious bugs get closed until the end of September. No known showstoppers are left :-)

=== Kate ===
*''current state:'' some missing features & bugs, but usable
*''contact:'' [mailto:kwrite-devel@kde.org Kate Team]
*''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
*''howto help:''
** <s>fix printing</s> Fixed by Anders, 2007-10-20
** fix shortcut settings
** rendering bugfixes
** config saving bugfixes
** testing
*''expected time of arrival:''

=== Printing ===
*''current state:'' showstopper
*''contact:'' [mailto:huntedhacker@tiscali.co.uk Alex Merry]
*''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
*help needed: Most of the necessary API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui. All current users of libkdeprint (ie: KPrinter) need porting to QPrinter/QPrintDialog/KPrintPreview. We currently have no way to print pdf or ps files directly (as used by Okular, for example). See [http://techbase.kde.org/Projects/KDEPrint/KDE4#Porting the kdeprint porting page]
*''howto help:'' send e-mail to the [mailto:kde-print-devel@kde.org kde-print-devel@kde.org] mailing list, or email the maintainer of a program volunteering to port its printing support.
*''expected time of arrival:'' Waiting on API decisions

=== Sound ===
*''current state:'' showstopper
*''contact:'' [mailto:kretz@kde.org Matthias Kretz]
*''goal:''
*# no showstopper: do some more automatic tests that all sound devices work as expected
*# done.
*#usable KMix
*#Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a showstopper for notification sounds. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
*''howto help:'' I certainly want help. But I don't know how I could label any of the tasks as small because for most things you need quite a good overview... :-( Mailinglists: [mailto:phonon-backends@kde.org phonon-backends@kde.org] or [mailto:kde-multimedia@kde.org kde-multimedia@kde.org], IRC: #phonon ping Vir
**Local audio playback is working quite OK, but there are some issues that are still open:
*** https://bugzilla.redhat.com/show_bug.cgi?id=284171
*** Sound hardware/ALSA setup
**** Currently the default list of audio devices to use is in arbitrary order. This needs to be fixed otherwise esd, artsd, jack or S/PDIF output can turn up as most preferred device and make it look like nothing is working. This might need something along the lines of a "hardware database".
**** There's a report that outputting to a dmix: ALSA device using a hardware mixing capable soundcard made mixing not work at all (don't ask me why), so the ALSA device name choosing algorithm might need to become a bit smarter. I think the safest bet for now is to use the default:CARD=... device string, but with that you can only choose what card you want, not what device on that card (I don't have hardware where this would make a difference, so no idea if it's needed).
**** Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
*** kmix is not in a good state (yet). Also it still does not react on plugged/unplugged soundcard or new/removed software control.
*** Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a big problem for notifications. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
*** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif
*''expected time of arrival:'' For 4. I have no idea because I don't know the cause. 3. is a bit out of my scope, though I might come up with a test app that does what I want soon...

Projects/Oxygen/StyleWinDec

2007-10-24T02:38:46Z

Mwoehlke: /* Known Bugs */

Projects/Oxygen/StyleWinDec

2007-10-23T20:47:41Z

Mwoehlke: (new) qtoolbox not drawn -> showstopper

Projects/Oxygen/StyleWinDec

2007-10-22T20:20:14Z

Mwoehlke: qa=thing to make sure we don't break, please don't remove :-)

Projects/Oxygen/StyleWinDec

2007-10-11T19:23:52Z

Mwoehlke: globalChange -> releasable (plus notes)

The current Oxygen style and window decoration for KDE4 can be found in SVN under http://websvn.kde.org/trunk/KDE/kdebase/runtime/kstyles/oxygen and http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/clients/oxygen

== Known Bugs ==
* tabs
** east and west aren't done at all priority
** no drawing of inactive tabs - only their text priority
* dockers
** frame when docked can be overwritten releasable
** frame when floating should have rounded corners releasable
* holes
** top color doesn't go around curves releasable
** [assigned: mwoehlke] color choice needs to be reviewed releasable
** with autoFillBackground, corners are overpainted (how to fix this??) priority
* toolbuttons
** glow color are not removed showstopper
* need to audit color role use (see QA #3) showstopper
* reverse layout is broken
** listview,tablevies etc paint the frame in LTR place showstopper
** groupboxes draw the heading too far to the right showstopper
** scrollbars draw the grove with wrong round ends showstopper
* progress bars not done showstopper
* menus not done releasable
* horizontal scrollbar looking a bit weird priority
* arrows in eg spinboxes not sharp enough priority
* windeco - corners should really be alpha transparent releasable
* should repaint on globalChange signal (how?) releasable
** this seems to only be a problem for the colors kcm, may not even be a style bug
* content padding in combo boxes too small (text/arrow touches left/right border) showstopper

== QA ==
* reverse layout
* high-contrast color schemes (i.e. all fg/bg black or white)
* reverse-light/dark color schemes (e.g. light-on-dark buttons with dark-on-light views, etc.)
* tabs, in all directions
* sliders, scrollbars, progress - in all orientations and good cross section of values
* content padding works for all controls, does not break sizeToContents functionality
* controls align nicely and controls that should be the same size, are

[[Category:Artwork]][[Category:Oxygen]]

Getting Started/Build/KDE4

2007-10-03T15:24:18Z

Mwoehlke: cs is not a typo

{{Template:I18n/Language Navigation Bar|Getting_Started/Build/KDE4}}

{{TutorialBrowser|

series=Getting Started|

name=Building KDE4 From Source|

pre=[[../../Sources/Anonymous_SVN|Anonymous SVN Quickstart Guide]]|

next=[[../../Set_up_KDE_4_for_development|Set up KDE 4 for development]]|

reading=[http://kdesvn-build.kde.org/ kdesvn-build: The KDE From Subversion Build Tool] [[../../Increased_Productivity_in_KDE4_with_Scripts|Increased Productivity in KDE4 with Scripts]] [[Development/Tutorials/CMake |Introduction to CMake]] [[../KDE4/FreeBSD|FreeBSD notes]] [[../KDE4/Mac OS X|Instructions for Mac OS X]] [[../KDE4/Windows|Instructions for MS Windows]]|
}}

== Abstract ==

This tutorial shows one way to get KDE from trunk running on Linux/BSD systems. There are also tutorials for [[/FreeBSD|FreeBSD]], [http://www.kdelibs.com/ Windows], [[/Mac OS X|Mac OS X]] and [http://solaris.kde.org/ Solaris]. Throughout the tutorial the bash shell is used.

{{warning|Expect a higher risk of build failure '''on Mondays''' when most kdelibs changes are committed. [http://developer.kde.org/~dirk/dashboard/ Dashboard] reports unexpected breakages. You are encouraged to fix failing modules.
}}

== Required Software ==

The following must be installed first before you can successfully complete this tutorial:
* gcc and g++, preferably version 4.1 or higher
* svn, the subversion revision control client
* pkg-config
* development libraries and headers for X11, OpenGL (mesa-common-dev and libglu1-mesa-dev), libjpeg, libpng, libungif, [http://clucene.sourceforge.net/index.php/Downloads libclucene], [http://download.librdf.org/source/ librdf], libxml2 and libxslt
* the <tt>makeobj</tt> script, which is part of kdesdk. You can install it as part of kdesdk (kdesdk-scripts on Debian) or similar package, or just download it itself from [http://websvn.kde.org/*checkout*/trunk/KDE/kdesdk/scripts/makeobj WebSVN]
* the [http://freedesktop.org/wiki/Software/shared-mime-info shared-mime-info package], which is the freedesktop MIME standard KDE is using now
* [http://boost.org/ boost], needed by kdebase; after compiling and/or installing boost, in order to make cmake aware about its location (FindBoost), add boost directory (the one containing include subdirectory) to CMAKE_INCLUDE_PATH or set an environment variable called BOOST_ROOT pointing to boost directory.

=== Ark Linux ===
In Ark Linux, the build dependencies you need are installed with:

<code bash>
apt-get install devel-core libxml-devel libxslt-devel bzip2-devel \
clucene-core-devel librdf-devel shared-mime-info xorg-Mesa-libGL-devel \
subversion boost-devel doxygen giflib-devel dbus-devel openssl-devel \
alsa-lib-devel kdesdk-scripts qt4-devel
</code>

If you prefer a graphical interface, select the packages listed above in the "Install Software" tool in Mission Control.

This includes installation of CMake, DBus and Qt - you can skip steps 5, 6 and 7.

=== Fedora ===

Some of the required packages for building KDE4 on Fedora 7 or higher:

<code bash>
yum install clucene-core-devel libxml libxml-devel libxslt-devel \
dbus-devel boost-devel bzip2-devel openssl-devel alsa-lib-devel \
redland-devel rasqal-devel raptor-devel hspell-devel aspell-devel \
cups-devel xine-lib-devel
</code>

=== Kubuntu and Debian ===

In Kubuntu 7.04 (Feisty) and Debian (Testing/Unstable) the build dependencies you need are installed with:
<code bash>
sudo aptitude install build-essential cdbs debhelper cmake \
libxml2-dev libxslt1-dev libbz2-dev libclucene-dev librdf-dev \
shared-mime-info libgl1-mesa-dev libglu1-mesa-dev mesa-common-dev \
libxext-dev libjpeg-dev libpng-dev subversion libsm-dev libxinerama-dev \
libxrender-dev libfontconfig-dev libboost-dev libxcursor-dev doxygen \
libungif4-dev libdbus-1-dev libgpgme11-dev libssl-dev libgpgme11-dev \
libasound2-dev kdesdk-scripts libpth-dev libjasper-dev \
ssh libxine-dev libqimageblitz-dev libqimageblitz4
</code>

In Kubuntu 7.10 (Gutsy) you have to add:
<code bash>
sudo aptitude install dbus-x11
</code>

For a fully functional API documentation framework you also need:
<code bash>
sudo aptitude install graphviz
</code>

=== openSUSE ===

In openSUSE 10.2 and newer, you can install packages using [http://en.opensuse.org/Zypper Zypper]:
<code bash>
sudo zypper install <package-name>
</code>

In older releases of SUSE, you can use YaST:
<code bash>
su
yast -i <packagename>
</code>

'''Required Packages'''

The packages you will need to install are:
<code>
xorg-x11-devel
libxml2-devel
kdesdk3
clucene-core-devel
boost-devel
libjpeg-devel
liblrdf-devel
libpng-devel
libxslt-devel
libredland-devel
Mesa-devel
giflib-devel
subversion
gcc
gcc-c++
gmp-devel (needed to build kdesupport)
strigi-devel (needed to build kdelibs)
gpgme-devel (needed to build kdepimlibs)
</code>

'''Optional Packages'''

You can skip the manual installation of Qt 4.3, CMake 2.4.6 and DBus by installing the adding the openSUSE Build Service KDE4 Repository to your installation sources.

For openSUSE 10.2 and newer do:
<code>
sudo zypper service-add http://software.opensuse.org/download/KDE:/KDE4/openSUSE_10.2 KDE4-102
</code>

For older versions of SUSE Linux do:
<code>
su
installation_sources -a http://software.opensuse.org/download/KDE:/KDE4/[YOUR SUSE LINUX VERSION]
</code>

Now install the following packages (and their dependencies):
<code>
cmake
dbus-1-devel
libqt4-devel
libqca2-devel (needed for building kdesupport)
</code>

And for fully functional apidox framework you also need:
<code>
graphviz
</code>

CMake binary packages for openSUSE are available from [http://software.opensuse.org/download/devel:/tools:/building/ openSUSE build service].

=== Gentoo ===

==== Install by hand ====

You can use stable ebuilds just remember to sync your portage before you begin.

Remember: All commands are executed as root.

Required:

We need to allow the following keyword masked ebuilds.

<code bash>
echo 'dev-util/cmake' >> /etc/portage/package.keywords
echo 'dev-cpp/clucene' >> /etc/portage/package.keywords
</code>

And now need to mask any Clucene versions above 0.9.16a.

<code bash>
echo '>dev-cpp/clucene-0.9.16a' >> /etc/portage/package.mask
</code>

Make sure you have set the berkdb USE flag for redland, otherwise nepomuk won't work.

<code bash>
echo 'dev-libs/redland berkdb' >> /etc/portage/package.use
</code>

These are the packages you will need to emerge, I included the update option into the emerge command so you will not re-emerge anything that you might already have installed.

<code bash>
emerge -avu 'sys-devel/gcc' \
'dev-util/subversion' \
'dev-util/pkgconfig' \
'x11-base/xorg-x11' \
'virtual/glut' \
'media-libs/mesa' \
'media-libs/jpeg' \
'media-libs/libpng' \
'media-libs/giflib' \
'dev-cpp/clucene' \
'dev-util/cppunit' \
'media-libs/liblrdf' \
'dev-libs/libxml2' \
'dev-libs/libxslt' \
'x11-misc/shared-mime-info' \
'dev-libs/boost' \
'dev-util/cmake' \
'dev-libs/redland' \
'sys-apps/dbus' \
'sys-apps/hal' \
'x11-libs/qt'
</code>

You will also need to emerge either 'kde-base/kdesdk' or kde-base/kdesdk-scripts'.

If you emerged DBUS, CMAKE, QT or HAL you may skip those sections respectively.
Good luck!

==== Install via portage ====

Also you can install the KDE 4 packages directly via
<code bash>
emerge -a <packagename>
</code>

To get the things you need, [http://gentoo-wiki.com/TIP_Overlays#Layman install layman] and then pull in the KDE overlay (which contains experimental KDE ebuilds):
<code bash>
layman -a kde
</code>
After this you need to adjust some USE-flags for KDE 4 and tell portage to use the testing KDE 4 ebuilds instead of the stable KDE 3 ones.

That way portage will do the dependency tracking for you.

Detailed instructions on building KDE 4 in Gentoo via portage can be found in the [http://overlays.gentoo.org/proj/kde/wiki KDE overlay wiki]. They are discussed in the thread [http://forums.gentoo.org/viewtopic-t-530111-postdays-0-postorder-asc-start-0.html KDE 4 monolithic ebuilds].

== Create a user account for KDE4 development ==

{{Note|
Some people like to have a separate user account for KDE 4 (for instance an old bug deleted files by mistake), and the instructions below were written with that approach.

However it is much more efficient to do everything with a single user account, see [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts|Increased Productivity in KDE4 with Scripts]]
for more details.

You can still follow the instructions below, but don't put the environment variables in your <tt>.bashrc</tt>, put them in a separate file that you source to switch to the KDE 4 environment.
}}

=== Option 1: Command Line ===
<code bash>
useradd -m kde-devel
passwd kde-devel
</code>

=== Option 2: Using KControl ===

Instead of using the commands above, you can also use the User module in the KDE Control Center if you already have KDE3 installed.

=== Setting up the environment ===

Copy the {{path|~/.bashrc}} from your normal user account to the new kde-devel account. Next, copy and paste the contents of the [[Getting Started/Increased Productivity in KDE4 with Scripts/.bashrc|example .bashrc]] into {{path|~kde-devel/.bashrc}}. Be sure to comment out the line <tt>alias make=makeobj</tt> if you do not have the <tt>[[Getting Started/Build/KDE4#Required Software|makeobj]]</tt> command available. You will probably also want to modify the path to make sure it doesn't include your kde3 paths. Also if you want to use KDevelop to develop KDE 4 applications you may pass the ''-GKDevelop3'' flag to the ''cmake'' command (to make CMake generate KDevelop project files, it will help to avoid rebuilding in the future, see [[Getting_Started/Set_up_KDE_4_for_development#Setting_up_the_environment|this]]).
To make it run, you have to open a new bash or to execute
<code bash>
source ~/.bashrc
</code>

This will provide access to commands such as <tt>cmakekde</tt> that are used in this tutorial as well as ensure that the proper paths are in place for Qt, KDE and CMake binaries.

For more information, please read the [[Getting Started/Increased Productivity in KDE4 with Scripts]] tutorial.

=== Switching to the New User ===
Switch to the user kde-devel: (don't forget the dash)
<code bash>
ssh -X kde-devel@localhost
</code>

{{Note|
If the ssh command fails, check out the "Launching KDE 4 apps" section of this KDE4 development guide:

http://techbase.kde.org/Getting_Started/Set_up_KDE_4_for_development#Launching_KDE_4_apps
}}

== The development user's shell ==

On some systems a new user is configured by default to use {{path|/bin/sh}}. If this is not the case on your system, you can skip this section. Using {{path|/bin/sh}} can be very inconvenient to work with and you may want to change it to {{path|/bin/bash}} or another shell.
On Ark Linux, you can skip this step - {{path|/bin/sh}} is {{path|bash}} on Ark Linux.

=== Option 1: As the kde-devel user ===

If you don't have root privileges and your system supports the changing of your own shell with the <tt>chsh</tt> application, then you could try to change your shell to {{path|/bin/bash}} by using:
<code bash>
chsh -s /bin/bash kde-devel
</code>

=== Option 2: As the root user ===

If your system comes with the <tt>usermod</tt> application you can run the following command as root: <tt>usermod -s /bin/bash</tt>.

Another option is to use the <tt>vipw</tt> application as root to safely edit your {{path|/etc/passwd}}. Locate 'kde-devel' in the the file. Change '{{path|/bin/sh}}' at the end of the line to read '{{path|/bin/bash}}', save your changes and exit.

The new shell will be started automatically when you log in as the kde-devel user again.

== D-Bus ==
QtDBus and KDE are known to work with D-Bus versions 0.62, as well as 0.92 and upwards. Versions 0.60 and 0.61 may work too but are not tested. Versions 0.90 and 0.91 are known not to work. We recommend using post-1.0 release versions (at least 0.94), so consider upgrading if you haven't done so.

You may skip this section if you have a recent D-Bus version or if you don't want to upgrade. You probably want to skip building the bindings until/unless you know you will be building HAL (see below).

Before running these steps in the recipe, make sure your X11 headers and libraries are available. The configure script run on line 5 of the following instructions should output:
Building X11 code: yes

=== The Recipe ===

{{tip|Make sure you did set up your environment correctly as described [[Getting_Started/Build/KDE4#Setting_up_the_environment|above]]. This is necessary for the <tt>cs</tt> and <tt>cb</tt> functions to work.}}

cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
wget http://dbus.freedesktop.org/releases/dbus/dbus-1.0.2.tar.gz
tar -xvzf dbus-1.0.2.tar.gz
cd dbus-1.0.2/
./configure --prefix=$DBUSDIR --localstatedir=/var
make
sudo make install
sudo dbus-uuidgen --ensure

cs # see above
wget http://dbus.freedesktop.org/releases/dbus-glib/dbus-glib-0.74.tar.gz
tar -xvzf dbus-glib-0.74.tar.gz
cd dbus-glib-0.74/
./configure --prefix=$DBUSDIR
make
sudo make install

=== What's Happening ===
After changing into the source directory (line 1), D-Bus source code is downloaded from freedesktop.org (line 2) and unpacked (line 3). After going into the newly created D-Bus directory (line 4), the build is set up using the supplied {{path|configure}} script (line 5). After building (line 6) and installing (line 7) D-Bus, we use the <tt>dbus-uuidgen</tt> tool to install a machine identification file that allows the bus to start automatically when the desktop session starts (line 8).

Note that you need write access to {{path|/var}} for the last two steps. If your system does not have the sudo command, you can use the <tt>su</tt> command instead, e.g. <tt>su -c "make install"</tt>.

The steps for building the glib bindings are similar to the above.

== CMake ==
Skip this if you have [http://cmake.org/ CMake] >=2.4.5 installed.
You should be able to directly use the binary packages available on the [http://www.cmake.org/HTML/Download.html CMake site]. There are also distribution specific packages available.

=== The Recipe ===


cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click Here to learn more]]
wget http://www.cmake.org/files/v2.4/cmake-2.4.6.tar.gz
tar -zxf cmake-2.4.6.tar.gz
mkdir cmake-build
cd cmake-build
../cmake-2.4.6/bootstrap
make
sudo make install

=== What's Happening ===
First, we go back to the <tt>kde-devel</tt> user's source directory (line 1), get the CMake sources (line 2) and unpack them (line 3). We create a directory to build CMake in (line 4) and go into it (line 5). We then run the CMake bootstrap script to set up the CMake build (line 6), then make (line 7) and install it (line 8) using the root user.

If your system does not have the <tt>sudo</tt> command, you can instead do <tt>su -c "make install"</tt>.

== Qt ==
Next we need to get the Qt4 that is in KDE's source repository. KDE is guaranteed to build against any Qt 4.3. Qt 4.2 and earlier are not supported and will not work. You should use the copy in the KDE Subversion servers. (note: some distros, like Debian, tend to supply Qt with patches from KDE svn applied, so you may want to cheat and use precompiled Qt from your distro)

=== The Recipe ===
cs # cs is not a typo
svn checkout svn://anonsvn.kde.org/home/kde/trunk/qt-copy
cd qt-copy
./apply_patches
./configure -qt-gif -no-exceptions -debug -fast \
-prefix $QTDIR -nomake examples -nomake demos
make -j2

# if we don't install, we'll just clear obj files to
# save disk space
if [ $QTDIR = `pwd` ]; then \
find . -name '*.o' -delete ; \
else make install; fi;

=== What's Happening ===
We switch back to the <tt>kde-devel</tt> user's home directory (line 1) and download the source code using subversion (svn) from KDE's repository (line 2). After changing into the resulting {{path|qt-copy}} directory (line 3), we run a script that manages the patches that come with <tt>qt-copy</tt> (line 4).

Once the patches have been applied, we then set up the build using the <tt>configure</tt> script (line 5-6). The various command line options used are explained in the {{path|qt-copy/README.qt-copy}} file. Finally, we build the minimal requirements for KDE (line 7) and install (line 10) Qt. If install dir is the same as the current dir (line 8), then we just free some space (line 9) instead. If you want all the example and demo applications, you can either build them individually or simply do a <tt>make</tt> from the {{path|qt-copy}} directory.

Note that the installation does not require root as it installs Qt locally into {{path|$QTDIR}}. Anyway, installation is only needed if {{path|$QTDIR}} differs from {{path|$HOME/qt-copy}}, which is not the case if you have exactly followed the instructions.

=== Troubleshooting ===
If you get "error: X11/Xlib.h: No such file or directory", install the devel package of <tt>xorg</tt> (the actual name may vary between operating systems, for example it is <tt>xorg-dev</tt> on Ubuntu based systems such as Kubuntu).

If you get an error in the configure step about missing defines, check the value of <tt>$QMAKESPEC</tt>. Some distributions set this to point directly to the system-installed Qt. If <tt>unset QMAKESPEC</tt> solves the problem, you probably want to add it to the <tt>~/.bashrc</tt> script.

If you get an error ".pch/debug-shared/QtCore", this is because Qt-4.3 enables precompiled headers if your gcc supports it, but for some reason it doesn't work for you. If you use distcc, configure qt with -no-pch. If you use icecream, update to the latest icecream from svn trunk.

Try running any Qt program, like {{program|assistant}}. '''Note:''' You may need to run <tt>xhost +local:kde-devel</tt> as your regular kde3 user to run this application. If it crashes in QSpanData::adjustSpanMethods, then your problem is the oxygen style. Try removing {{path|lib/kde4/plugins/styles/kstyle-oxygen.so}} and {{path|lib/kde4/plugins/styles/oxygen.so}} if they exist in the KDE install prefix.

== HAL ==

{{tip|You can use qdbusviewer to see if you have org.freedesktop.hal. If not, you might need a newer version of hal. If you have org.freedesktop.hal, you probably don't need to, and don't ''want'' to, roll your own HAL.}}

If your system requires you to build a newer version of HAL, there's a decent chance you'll need to build other stuff as well, some of which may not be straight forward. Since this should only be required for older distros, instructions are on [[Getting_Started/Build/HAL| a separate page]].

== kdesupport ==

{{warning|Don't forget to read the [[Getting_Started/Build/KDE4#Setting_up_the_environment|Setting Up The Environment]] section first.}}

There are several libraries that KDE applications rely on in the kdesupport module. This includes Strigi and Soprano for file metadata and search, QImageBlitz for image manipulation needed in kdebase, eigen for visual effects in applications such as Kalzium, taglib for music players and qca for some cryptographic needs.

Strigi itself has a few dependencies as well: you will need the libraries and headers for libz, libbz2, openssl (libcrypto or libssl), libclucene (>=0.9.16a but watch out: version 0.9.17 does '''not''' work), and either libxml2 or libexpat.

=== The Recipe ===

cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/kdesupport/
cd kdesupport
cmakekde

=== What's Happening ===
We change to the base source directory (line 1). We download the sources in kdesupport using subversion (line 2), go into the new {{path|~/kde/src/kdesupport}} directory (line 3), and commence the build (line 4). This will leave us in the kdesupport build directory after the build is completed.

=== Troubleshooting ===
If you get
cmakekde: command not found
then you have to go manualy into the kdesupport directory in ~ and execute the command cmakekde. if this still doesnt work, then something is wrong with your bashrc.

If you get
CMake Error: This project requires some variables to be set,
and cmake can not find them.
Please set the following variables:
LIBXML2_INCLUDE_DIR (ADVANCED)
you should install the development package for libxml2.

If you get
CMake Error: Could NOT find REDLAND
then you need librdf from the Redland.
If your distribution does not provide the librdf package, you can download the source there: [http://download.librdf.org/source/ http://download.librdf.org/source/] and build it.
(Gentoo users: The ebuild for librdf is named dev-libs/redland)

If you get
Fetching external item into 'kdesupport/admin'
Error validating server certificate for 'https://...'
see [http://techbase.kde.org/Getting_Started/Sources/Using_Subversion_with_KDE Using Subversion with KDE]

If you get
FILE cannot create directory: /usr/lib[64]/qt4/plugins/crypto. Maybe need administrative privileges.
- - -
make: *** [install] Error 255
take a second look in the .bashrc file described above, are paths correct? Alternatively, you may see this error if you decided to use a distribution installed version of qt4 and skipped the Qt install above. Either install qt-copy as describe above, or "sudo make install". If you use "sudo make install", make sure you that you change the ownership back to your user for some of the ~/kde subdirectories that were effected by using sudo (ie. "<tt>sudo chown -R kde-devel:kde-devel ~/kde</tt>").

== kdelibs ==

We can now move on to building KDE's base libraries.

=== The Recipe ===
cd
cs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
mkdir KDE && cd KDE
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
cd kdelibs
cmakekde

=== What's Happening ===
We change to the base source directory (line 1) then make and go into the KDE directory (line 2). We download the sources for kdelibs using subversion (line 3), go into the new {{path|~/kde/src/KDE/kdelibs}} directory (line 4), and commence the build (line 5). This will leave us in the <tt>kdelibs</tt> build directory after the build is completed.

{{tip|There might be missing dependencies on your system! They are easily overlooked in the output of <tt>cmakekde</tt>.
You might want to do a <tt>cmake $KDE_SRC/KDE/MODULE_NAME</tt> prior to compiling any kde modules (like kdelibs, kdepimlibs etc.)}}

=== Additional KDE-specific CMake modules ===
There are additional CMake modules in {{path|kdelibs/cmake/modules/}} that are necessary for building KDE4 applications. These will be installed for you when kdelibs itself is installed.

=== Troubleshooting ===
If you have problems compiling kdelibs, first make sure the software in the [[Getting_Started/Build/KDE4#Required_Software|Required Software]] section above is installed and works. Other possible hints include:
* If the <tt>cmakekde</tt> command fails stating that CMake requires an out of source build directory, remove {{path|~/kde/src/KDE/kdelibs/CMakeCache.txt}}, and try again.

If <tt>cmakekde</tt> still gives the same error then try this
cd
cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR \
-DCMAKE_BUILD_TYPE=debugfull \
-DKDE4_BUILD_TESTS=ON \
~/kde/src/KDE/kdelibs
make
make install
* If you received an error stating "Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there.", then you need to change to your build directory before running cmakekde. (e.g <tt>cs KDE/kdelibs && cb && cmakekde</tt>) If the message stays, run 'svn status' in the kdelibs directory and remove all files labeled with '?'.
* If Qt wasn't found or the wrong version of Qt was found, make sure that the qmake from the Qt you need is the first qmake in the path.
* If the problems persist, try the CMake make-option <tt>--keep-going</tt>.
* Here you need the libungif library, otherwise you will get an error message like "<tt>Could NOT find GIF</tt>".
* Qt-4.3 upgrade: if you get a link error in kjsembed talking about QScriptEngine, edit CMakeCache.txt in kdelibs and remove the lines that talk about QT_QTUITOOLS_LIBRARY, then type make again (that static library has a new dependency, and the cmake code that adds it needs to run).
* if you get <code>CMake Error: KDE Requires Qt to be built with SSL support
</code>, install openssl-devel, remove CMakeCache.txt and re-compile QT.
* if you get <code>kdelibs/kimgio/ico.cpp:188: undefined reference to `QImage::jumpTable()'</code> it means you compiled QT without QT3 support(no, linking to a true QT3 install won't work)

== kdepimlibs ==
After <tt>kdelibs</tt>, but before ''kdebase'', you need to build and install ''kdepimlibs''.

=== The Recipe ===

cs KDE # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepimlibs
cd kdepimlibs
cmakekde

=== What's Happening ===
We go into the KDE source directory (line 1), download the source code for kdepimlibs using subversion (line 2) and then go into the new {{path|~/kde/src/KDE/kdepimlibs}} directory (line 3). We then commence the build (line 4). This will leave us in the <tt>kdepimlibs</tt> build directory after the build is completed.

=== Troubleshooting ===
If you have trouble compiling kdepimlibs:
* the cmakekde command may require a later version of the gpgme library. This is available from the project's web site: http://www.gnupg.org/(en)/download/index.html - please note that the build of gpgme also requires libgpg-error, also available from the same location. Both libraries are installed by the "./configure", "make" and "sudo make install" sequence, with the gpgme library configured with the additional "--with-gpg-error-prefix" parameter. You may need to overwrite your existing "/usr/bin/gpgme-config" file with the newer version for the kdepimlibs to pick up the new install.

== kdebase ==
kdebase is divided into three parts:
* '''apps'''
:This contains applications like Dolphin or KWrite.
* '''runtime'''
:This contains things needed by every application at runtime, like icons. It is a required dependency for each KDE application, so you have to compile and install this.
* '''workspace'''
:This contains things specific to the KDE desktop, like Plasma or the window manager. Most stuff here depends on X11. You only need it if you want to build a full KDE desktop.

You can build all of kdebase at once, which is described in the recipe below. If you only want to build kdebase-runtime, which is the only requirement, you can replace <code bash>cd kdebase</code> with <code bash>cd kdebase/runtime</code> in the recipe below.

=== The Recipe ===

cs KDE # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
cd kdebase
cmakekde

=== Troubleshooting ===
If you have troubles compiling kdebase:
* Make sure you have the <tt>libxss headers</tt> installed. (Usually you got undefined references on xscreensaver objects if you do not have those headers)
* <tt>which meinproc</tt> has to deliver {{path|/home/kde-devel/kde/bin/meinproc}}
* if cmakekde can not find the path of kdepimlibs, edit the file {{path|$KDE_BUILD/KDE/kdebase/CMakeCache.txt}} and manually set <tt>KDEPIMLIBS_INCLUDE_DIR:PATH=$KDE_BUILD/kdepimlibs</tt>
* if you get an error saying "Please set the following variables: X11_XTest_LIB (ADVANCED)", install the devel package of <tt>Xtst</tt>. On some systems, this is packaged separately from <tt>xext</tt> and called <tt>x11proto-xext-dev</tt> or <tt>libxtst-dev</tt>. You may also need to remove the CMakeCache.txt file in the build dir after installing the package.
* the same for "X11_Xinerama_LIB (ADVANCED)" where you will need the devel package for <tt>xinerama</tt>.
* if you get an error complaining about a missing variable X11_Xrandr_LIB, you need the devel package for libxrandr (libxrandr-devel on ubuntu-systems)
* if you get the error "Please set the following variables: FONTCONFIG_INCLUDE_DIR, FONTCONFIG_LIBRARIES (ADVANCED)", then you need to install the libfontconfig headers
* if you get the error "CMake Error: This project requires some variables to be set, and cmake can not find them. Please set the following variables: KMETADATA_LIBRARIES", you need to install soprano from kdesupport and to rebuild kdelibs
* if you get the error "‘XserverRegion’ does not name a type" make sure you have libxcomposite headers installed (<tt>libxcomposite-dev</tt> in ubuntu)
* if you get the error "CMake Error: This project requires some variables to be set, and cmake can not find them. Please set the following variables: QT_QTOPENGL_LIBRARY (ADVANCED) ", try editing CMakeCache.txt and setting QT_QTOPENGL_LIBRARY:FILEPATH=/home/kde-devel/qt-copy/lib/libQtOpenGL.so

* if you get messages as "KDE4_INSTALL_HANDBOOK() is deprecated. Remove it please. Now all is done in KDE4_CREATE_HANDBOOK." then, either find the files containing the offending line and comment it out manually, or run the following script in ~/kde/src/KDE/kdebase: [http://www.plamadeala.com/files/macros_corrector.sh macros_corrector.sh]. It will just REMOVE the line that has "kde4_create_handbook" in it from all the found files.

== Running KDE 4 programs ==

You can now run KDE 4 programs (e.g. kwrite) by typing:
ssh -X kde-devel@localhost
kwrite

=== Troubleshooting ===

* If you get
KUniqueApplication: Cannot find the D-Bus session server
check if you can access the display, e.g. type
xclock
and see if a clock appears on the screen.

* If you get something like
Error: standard icon theme "oxygen" not found!

ASSERT: "!isEmpty()" in file /home/kde-devel/qt-copy/include/QtCore/../../src/corelib/tools/qlist.h, line 245
Aborted (core dumped)
You need to install kdebase - see above. It is enough to install the "runtime" directory from kdebase.

== Generating local API documentation ==
Although the API documentation for KDE is available online at [http://api.kde.org api.kde.org], it is sometimes useful to have it on your own disk, for example when you want to use [[Getting_Started/Set_up_KDE_4_for_development#KDevelop|KDevelop]] for browsing the documentation or when you are not able to be online all the time.

Be aware that generating the API documentation can take several hours and takes almost half a gigabyte of diskspace.
The generation is handled by a script in {{path|kdelibs/doc/api}}, you need <tt>doxygen</tt> to be able to run it.

To build the API documentation for kdelibs, type the following:

cs KDE/kdelibs # [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|'cs' is a bash function, click here to learn more]]
$KDE_SRC/KDE/kdelibs/doc/api/doxygen.sh \
--doxdatadir=$KDE_SRC/KDE/kdelibs/doc/common .

Repeat for other modules as desired. 
cd <module home>
$KDE_SRC/KDE/kdelibs/doc/api/doxygen.sh \
--doxdatadir=$KDE_SRC/KDE/kdelibs/doc/common .

Another, even easier method involves downloading this [[Doxyfile]] to your local system. Then simply change directory to where you want to create the documentation and run
<code bash>
% doxygen /path/to/Doxyfile
</code>
Then review the file {{path|doxygen.log}} to see the doxygen errors and warnings. You'll find the actual documentation in the {{path|apidocs}} subdirectory.

== Staying up to date ==

In order to keep the kde4 installation up to date, each of the modules installed should be updated periodically. As Monday is the day for big changes in kdelibs, Tuesday may be the best day to do this. For each module checked out, run <tt>svn up</tt> and <tt>make</tt>.

For example:
<code bash>
cs kdesupport # cs is not a typo
svn up
cb # cb is not a typo
make -j2 VERBOSE=1 && make install
</code>

== Installing a subset of a module ==

Many modules in KDE contain a large number of programs which could take a long time to download and compile. In cases where you want to work only on a particular program or programs in a module, it is possible to download and compile particular folders. In some cases, certain folders are required for any build of the module. This is determined in the CMakeLists.txt file of the module. For example the [http://websvn.kde.org/trunk/KDE/kdegames/CMakeLists.txt?view=markup kdegames CMakeLists.txt file] lists:

<code>
add_subdirectory(libkdegames)
add_subdirectory(libkmahjongg)

macro_optional_add_subdirectory(doc)
macro_optional_add_subdirectory(lskat)
macro_optional_add_subdirectory(katomic)
</code>

So, the libkdegames and libkmahjongg directories are required to build any of kdegames. The cmake directory will also usually be required. All the other directories (doc, katomic etc) are optional. They will be built if present on your machine. In this example, we build kmahjongg and kbattleship:

<code bash>
cs KDE
svn co -N kdegames # The -N switch performs a non-recursive checkout
cd kdegames
svn up libkdegames # Get required directories
svn up libkmahjongg
svn up cmake
svn up kbattleship # Get optional directories
svn up kmahjongg
cmakekde
</code>

== General troubleshooting ==

What can happen over time, after some <tt>svn up</tt> commands, is that some of the tools used in the KDE build chain change their output format. For example, <tt>kcfg</tt> files are read by <tt>kconfig_compiler</tt> to produce configuration dialogs. CMake cannot detect those changes, and the compilation might fail. A workaround is to always force a re-generation of all such files:
find $KDE_SRC/KDE/kdebase -name "*.kcfg" | xargs touch
The same applies to <tt>ui</tt> files as produced by Qt designer.

== Success! ==

You are now ready to start building other svn modules in the same fashion as you built kdebase, running and testing KDE4 or writing your own patches and applications.

See the [[Getting Started/Set up KDE 4 for development|Set up KDE 4 for development]] tutorial for how to start KDE 4 applications and how to use KDevelop to work on them.

[[Category:Build KDE]]
[[Category:KDE4]]