KWin

Topics for official discussion

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 and Wayland

There is no doubt about it that Wayland [1] 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.

The first major point we need to discuss is to whether to split our development effort and write a new KWin core from scratch 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 (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 and feature limiting sections below.

At this particular point of time (09:00, 4 December 2010 (UTC)) I (Lmurray) do not have much technical knowledge relating to how Wayland works. According to the Wayland architecture overview [2] it is the compositor's job to handle keyboard and pointer input. This brings me to two points:

1. global shortcuts, and
2. 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 (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 (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 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 Lmurray 11:39, 29 November 2010 (UTC))
• PaintClipper calls glDrawArrays() once per clip rectangle. -- fredrikh (Paraphrased by 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 [3] and makes sense to be used within a core KDE project. -- Lmurray 11:39, 29 November 2010 (UTC)

APIs are poorly designed

APIs should use Qt signals and slots [4] as well as the Qt property system [5] instead of large amounts of virtual functions. -- fredrikh (Paraphrased by 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. -- Lmurray 11:39, 29 November 2010 (UTC)

Useful IRC logs

TODO