All You Need to Know About K Desktop Environment

K Desktop Environment, abbreviated as KDE by abbreviationfinder, has its own input / output system called KIO, which can access a local file, a network resource (through protocols such as HTTP, FTP, NFS, SMB, etc.), or virtual protocols (Camera of photos, compressed file, etc.) with absolute transparency, benefiting every KDE application. KIO’s modular architecture allows developers to add new protocols without requiring modifications to the base of the system.

Finally, (KParts) allows you to include applications within others, thus avoiding code redundancy throughout the system. Additionally, it has its own HTML engine called KHTML, which is being reused and expanded by Apple (to create its Safari browser), and by Nokia.

KDE Project

As the project history shows, the KDE team releases new versions in short periods of time. They’re renowned for sticking to release plans, and it’s rare for a release to be more than two weeks late.
One exception was KDE 3.1, which was delayed for over a month due to a number of security-related issues in the codebase. Keeping strict release plans on a voluntary project of this size is unusual.

Major releases

A major release of KDE has two version numbers (for example KDE 1.1). Only the major releases of KDE incorporate new functionality. There have been 16 major releases so far: 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0, 4.1, 4.2, 4.3, and 4.4. All releases with the same major version number (KDE 1, KDE 2, KDE 3, and KDE 4) are supported in both binary code and source code. This means, for example, that any software developed in KDE 4.2.X will work with all KDE 4 releases.

Except during major version changes, alterations never occur with requirements for recompiling or modifying the source code. This maintains a stable API (Application Programming Interface) for KDE application developers. The changes between KDE 1 and KDE 2 were large and numerous, while the API changes between KDE 2 and KDE 3 were comparatively minor. This means that applications can be easily transformed to the new architecture.

Major version changes to KDE are intended to follow those of the Qt Library, which is also under constant development. So, for example, KDE 3.1 requires Qt ≥ 3.1 and KDE 3.2 requires Qt ≥ 3.2. However, KDE 4.0 requires Qt ≥ 4.3 and KDE 4.1 requires Qt ≥ 4.4.

As soon as a major release is ready and announced, it is added to the svn repository “branch”, while work on the next major release begins on the main one (trunk). A major release takes several months to complete, and many bugs found during this stage are removed from the stable branch as well.

Minor releases

Less separate release dates are scheduled for minor releases. A minor KDE release has three version numbers (for example KDE 1.1.1) and the developers focus on fixing bugs and improving minor aspects of the programs instead of adding functionality.

Critics

• KDE was criticized in its early days because the library on which it is developed (Qt), despite following a development based on open source, was not free. The 4 as September as 2000, the Library began distributing licensed under the GPL 1 and criticisms were gradually ceasing. Currently, and since version 4.5, the library is additionally available under LGPL 2.1.
• Some outsiders criticize KDE’s similarity to the Windows Desktop Environment. This observation, however, falls on the selection of predefined parameters of the environment; often aimed at making it easier to use for new users, most of whom are used to working with Microsoft operating systems. However, KDE has a high configuration capacity and in its branch 4 it has desktop effects integrated in Plasma and KWin, comparable to those of Compiz.

Project Organization

Like many other free projects, KDE is built primarily through the effort of volunteers. Since several hundred individuals contribute to KDE in various ways (programming, translating, producing art, etc.), organizing the project is complex. Most of the issues are discussed on the different project mailing lists.

Contrary to what you might think of such a large project, KDE does not have a centralized leadership; Matthias Ettrich, the founder of the KDE project, does not have much weight over the decisions and direction of the KDE project. Important decisions, such as release dates or inclusion of new applications, are made by the main developers on a restricted mailing list. Lead developers are those who have contributed to KDE for a long time. Decisions are not made in a formal voting process, but rather through discussion on the mailing lists. Generally this method works very well.

Any user is welcome to report bugs he has found in the Software (“bug”). It is also possible to make requests about new functionalities (“wish”). It is enough to communicate it, in English, on the website enabled for it: KDE Bug Tracking Syst en. In legal and financial matters, the KDE Project is represented by the KDE eV, a German non-profit organization.