KWin

From KDE Community Wiki
Revision as of 11:39, 29 November 2010 by Lmurray (talk | contribs) (Initial population based on yesterday's discussion in #kwin)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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 [1] 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 [2] as well as the Qt property system [3] 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