|
|
| (25 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| | [[File:Mascot konqi-base-plasma.png|thumbnail|right|Move the windows with [[Konqi]]!]] |
| == Developer Documentation == | | == Developer Documentation == |
| There are several sub sides with some developer documentation: | | There are several subsites with some developer documentation: |
| * [[KWin/Hacking]] General development information | | * [[KWin/Hacking]] General development information |
| | * [[KWin/Building]] How to build KWin from master |
| | * [[KWin/Getting_Involved]] How You could get involved in KWin development |
| | * [[KWin/Frameworks]] How to build KWin on frameworks and help porting |
| | * [[KWin/Dependencies]] Dependencies of KWin on frameworks 5 |
| | * [[KWin/KConfigXT_Effects]] Project: Port Effects to KConfigXT |
| | * [[KWin/KConfigXT]] Project: Create KConfigXT for KWin core |
| | * [[KWin/Animations]] Project: Find all animation details in Effects |
| | * [[KWin/Default_Options]] Default Options Project for 4.9 |
| | * [[KWin/Ideas]] Ideas for small tasks in KWin |
| | * [[KWin/Environment_Variables]] Overview on the available environment variables in KWin |
| | * [[KWin/Wayland]] General information about KWin and Wayland |
| | * [[KWin/Wayland_Development]] Information for developing KWin + Wayland |
| | * [[KWin/QT5]] Progress on making KWin ready for QT5 |
| * [[KWin/Bugzilla]] Information on Bug Triaging | | * [[KWin/Bugzilla]] Information on Bug Triaging |
| * [[KWin/Class_Diagram]] Class Diagram of KWin | | * [[KWin/Class_Diagram]] Class Diagram of KWin |
| * [[KWin/Shadow]] New Shadow System (Discussion) | | * [[KWin/Shadow]] New Shadow System |
| * [[KWin/Screen_Edges]] New Screen Edge Handling (Discussion) | | * [[KWin/Screen_Edges]] New Screen Edge Handling |
| | | * [[KWin/Decoration]] New Window Decoration API (Discussion) |
| ==Topics for official discussion==
| | * [[KWin/Screenlocker]] Moving Screenlocker to KWin (Discussion) |
| | | * [[KWin/GSoC/Modularization]] Documentation for GSoC Modularization of KWin |
| All these need to be discussed with '''all''' active KWin developers and relevant parties. These discussions also need to be documented and followed-up on for future reference. Since this process can take a while it is best to not get ahead of ourselves and rush them.
| | * [[KWin/GSoC/Color_Correction]] Information about the GSoC Color Correction project |
| | | * [[KWin/Mission_Statement]] Mission Statement for KWin (Discussion) |
| ===KWin and Wayland===
| | * [[KWin/Changelog_5]] Changelog of new features in KWin 5 |
| | | * [[KWin/Debugging]] Debugging the compositor with gdb is extra tricky, thus here a chaet sheet |
| There is no doubt about it that Wayland [http://wayland.freedesktop.org/] is going to become popular in the future and if we, the KDE community, can port the entire KDE workspace without losing any important features then it'll definitely become a viable alternative to Xorg. As KWin is very important to the KDE workspace and as it is '''extremely''' dependent on the X11 protocol we need to seriously discuss our plan of action, and soon.
| | * [[KWin/Packaging]] Packaging documentation in particular WRT X11 vs. Wayland |
| | | * [[KWin/Window_Metadata]] DBus protocol for passing additional window information |
| The first major point we need to discuss is to whether to split our development effort and write a new KWin core from scatch—copying known good code from the existing codebase but reviewing everything—specifically for Wayland that can interface with our higher-level modules such as decorations and desktop effects or to slowly restructure our existing core over a period of time to separate the X11 code from the core KWin logic. I ([[User:Lmurray|Lmurray]]) personally believe the latter is the better course of action but we will need to make sacrifices for it to succeed as I believe the current KWin codebase is far too large for us to maintain. For more details on this topic refer to the [[#Code restructuring|code restructuring]] and [[#Feature limiting|feature limiting]] sections below.
| |
| | |
| At this particular point of time (09:00, 4 December 2010 (UTC)) I ([[User:Lmurray|Lmurray]]) do not have much technical knowledge relating to how Wayland works. According to the Wayland architecture overview [http://wayland.freedesktop.org/architecture.html] it is the compositor's job to handle keyboard and pointer input. This brings me to two points:
| |
| | |
| # global shortcuts, and
| |
| # focus stealing prevention.
| |
| | |
| Handling global shortcuts in KWin isn't really much of an issue if we take the easy way out and proxy everything to kglobalaccel. The only thing I ([[User:Lmurray|Lmurray]]) dislike about that is that it means we will be making unnecessary inter-process communication every time the user presses a key on the keyboard. It is possible to implement a key grabbing system similar to Xorg that will only proxy pre-registered key combinations to kglobalaccel but then things are getting slightly more complex and we might as well just dynamically link kglobalaccel or something straight into the compositor.
| |
| | |
| Focus stealing prevention is not something that I ([[User:Lmurray|Lmurray]]) have thought of much at this particular point of time (09:00, 4 December 2010 (UTC)) but is just something I want to mention before it is forgotten.
| |
| | |
| ===Code restructuring===
| |
| | |
| * Is it worth slowly restructuring core code to become more modular?
| |
| ** Will be easier to port to Wayland.
| |
| ** Does this extend what Martin is already doing with GL ES?
| |
| * Create a list of all classes in KWin so we can work out how modular things are.
| |
| ** Think up ideal object interfaces, both public and internal, for every part of KWin. Compare these ideals with what KWin already has and see if it's possible to slowly adjust the code over time.
| |
| ** If it's not possible to use the ideal then comprimise until it is possible.
| |
| | |
| ===Feature limiting===
| |
| | |
| * Sacrifice for a net benefit.
| |
| * Is KWin too large for its active developer base?
| |
| * What is our official target audience and should we concentrate development towards it? Not 100% focus but definitely at least not accept any patches that can potentially affect the target audience negatively in the short or long term.
| |
| ** Don't just blindly accept a target audience given to us by non-KWin developers if it causes our developers to lose interest. That being said try to lean towards KDE's overall target audience where possible.
| |
| ** Each individual developer may have a different target audience but targetting more than one group can end up with mutual exclusivity which leads to inconsistency.
| |
| ** Identify which features are often used by the target audience and improve those features more often.
| |
| ** Can the less-used features be ported to scripts?
| |
| *** Window rules can easily be handled by scripts. Ease-of-use can be handled with good examples that can be easily modified.
| |
| * Create a list of all configurable features KWin and discuss each one in depth
| |
| ** Work out which are holding us down and remove them if it is beneficial to do so (I.e. there's no point removing a feature if it doesn't make it easier to maintain KWin).
| |
| ** Don't start with the effects... they get more than enough attention already. | |
| | |
| ===Unsorted===
| |
| | |
| * Create and document an official review process.
| |
| * Create, use and endorse unit tests. They are a great way of helping modularize code and make features easier to maintain.
| |
| * Identify and remove wishlist items which will never be realisticly actioned in the short- to medium-term. Good ideas are not sparse so there is no point in keeping the older ones around.
| |
| * Should we be actually aiming our development on today's FOSS graphics stack instead of the closed-source ones? Things may be slightly uglier but with proper abstraction and OOP concepts it can still work out.
| |
| ** Effectively trading in ease of development for increased system support and stability.
| |
| ** Also makes KWin and KDE in general more viable for distribution defaults.
| |
| * What is our official stance on revolution vs evolution?
| |
| ** Revolution may be nice and newsworthy but it can very easily alienate users if not done correctly. A large portion of people don't like change. | |
| ** It also affects configuration defaults, particularly in upgrade scripts.
| |
| | |
| ==Unsorted/undebated TODO==
| |
| | |
| * If WindowQuadList used floats instead of doubles it could be possible to point glVertexPointer() directly instead of doing unnecessary copying and conversion every paint call. -- '''fredrikh''' (Paraphrased by [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC))
| |
| * EffectFrame and EffectWindow are basically the same thing from an effect's point of view; a texture and a set of vertices and texcoords. They could share the same base class. -- '''fredrikh''' (Paraphrased by [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC))
| |
| * PaintClipper calls glDrawArrays() once per clip rectangle. -- '''fredrikh''' (Paraphrased by [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC)) | |
| | |
| ==Detailed TODO==
| |
| | |
| ===Coding style===
| |
| | |
| Fredrikh and myself discussed coding styles on IRC briefly a few weeks ago (I do not have the logs) and decided that the Qt coding style with some minor adjustments would be best for KWin as it's well documented [http://qt.gitorious.org/qt/pages/QtCodingStyle] and makes sense to be used within a core KDE project. -- [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC)
| |
| | |
| ===APIs are poorly designed===
| |
| | |
| APIs should use Qt signals and slots [http://doc.qt.nokia.com/4.7/signalsandslots.html] as well as the Qt property system [http://doc.qt.nokia.com/4.7/properties.html] instead of large amounts of virtual functions. -- '''fredrikh''' (Paraphrased by [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC))
| |
| | |
| :For system software, such as KWin, that communicates a lot with external processes all the time it makes sense to attempt to make as much of the KWin code event based as possible, especially as all the low-level code already does so. This applies to pretty much every KWin object and not just the public APIs. While it does make it slightly more difficult for inexperienced developers to understand and to debug in general due to losing full stack traces it can vastly improve the responsiveness and efficiency of KWin as a whole. -- [[User:Lmurray|Lmurray]] 11:39, 29 November 2010 (UTC)
| |
| | |
| ==Useful IRC logs==
| |
| | |
| TODO
| |
