From 4f12f43d5df515579232dd63378e312b1ec6c257 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Gr=C3=A4=C3=9Flin?= Date: Sun, 20 Feb 2011 18:22:10 +0100 Subject: [PATCH] Clean up documentation in KWin * COMPOSITE_TODO lists many tasks already implemented or not valid any more, it's easier to just write a new document with concrete tasks in the wiki * NEWCOLORSCHEME.README has been unchanged since it's first introduction in 2000. Does not sound any "new" to me and lists changes compared to KWM * clients/PORTING: all important clients have been ported and what is not yet ported will probably never get ported. The unported decos have been moved to unmaintained some time ago. * clients/REQUIREMENTS_FOR_CVS: well the requirements are not valid any more. --- COMPOSITE_TODO | 219 ----------------------------------- NEWCOLORSCHEME.README | 44 ------- clients/PORTING | 29 ----- clients/REQUIREMENTS_FOR_CVS | 20 ---- 4 files changed, 312 deletions(-) delete mode 100644 COMPOSITE_TODO delete mode 100644 NEWCOLORSCHEME.README delete mode 100644 clients/PORTING delete mode 100644 clients/REQUIREMENTS_FOR_CVS diff --git a/COMPOSITE_TODO b/COMPOSITE_TODO deleted file mode 100644 index 7ee3200d8f..0000000000 --- a/COMPOSITE_TODO +++ /dev/null @@ -1,219 +0,0 @@ -This file lists TODO items for the compositing code. - -See file COMPOSITE_HOWTO for setting up kwin_composite. -See file HACKING for details on developing KWin, including building - the kwin_composite branch. -See effects/howto.* for a HOWTO on writting effects. -See documentation in source (mainly in scene.cpp) for description - of the design of the compositing framework. - -TODO -================================= - -* = not done, will be either done by me, or should be at least discussed first with me -+ = not done, I don't plan on doing it that soon - - in other words, these should be the best ones for you if you want to help -! = like +, but they should be relatively simple - - in other words, these should be the best if you want to get started with the code -/ = work in progress -? = should it be done? -% = should be probably done later, during cleanups and preparations for being stable - - -KDE 4.0 TODO -================================= - -- effects (to do) - - add generic support to use effect only for certain window types [Seli] - -- window-specific rules need to apply to unmanaged windows as well (where applicable) -- some window-specific rules also related to compositing - - opacity - -/ handling of window pixmaps for unmapped windows [Seli] - - config option? - -- shm mode needs support for more data formats than GL_BGRA - -- check what works with XRender - -- documentation - -- disable application effects when kwin can provide them, e.g. shadow/transparency - - -General TODO -================================= - -+ suspend repaints if not visible or dpms is active - - there is already 'overlay_visible', but it still polls the mouse in such case - - it should turn off the timer - -? wait for decoration repaints - - it is sometimes visible that the window contents are painted first and the decoration - only afterwards with a small delay -? - this has been already greatly improved by r632378, so it's maybe not worth it anymore - - maybe posted paint events need to be processed immediatelly, or maybe the compositing - code should not update the window until the decoration is finished painting - -% paint throttling - - there's 5ms grace period per repaint to avoid overloading the system with just compositing - and not letting the system do anything else - check and evaluate - -* handle properly stacking order of deleted windows for showing in effects - -* handle properly deleted windows that reappear (windowReadded() function?) - -% during screensaving, do no let non-screensaver windows show above screensaver - - kdesktop_lock watches for such things and raises again, but there's a small gap - -% nvidia drivers by default use fake refresh rates as a workaround for some X limitations - - see the DynamicTwinView section in nvidia README - - this makes KWin repaint at a different rate than it should - -/ handling of window pixmap for unmapped windows - - currently it's kept around after a window is unmapped -* - but it's still discarded on e.g. resize - how to solve this? -* - windows could be unmapped but quickly mapped back when a live thumbnail is needed - -* window grouping is not implemented for unmanaged windows (used e.g. by DimInactive) - -% clean up and sort out shortcuts so that they don't conflict and make sense - -? hidden previews currently needs input shape extension, otherwise the window can possibly interfere - - not very likely though, so is this worth bothering at all? - - -OpenGL TODO -================================= - -/ Check/make it work with other gfx cards - -% Xgl support - - should work - - in SceneGL::Texture::findTarget() there is a hack that makes KWin work with XGL - without requiring KWin to be built against the libGL version that Compiz is - built against -% - that may not be necessary somewhen later - - interesting observation: normally run glxgears performs somewhat poorly compared - to normal nvidia mode, changing glxgears to be override-redirect (i.e. no reparenting) - however makes glxgears to be even faster than without any compositing at all, - in this case however kwin's redrawing speed drops somewhat - -% AIGLX support - - should work - -/ GL_ARB_texture_rectangle vs GL_ARB_texture_non_power_of_two -% - works; bugs in tfp_mode with power_of_two textures - - ati (others?): power_of_two windows are drawn white unless non-tfp_mode - is forced in findTextureTarget() - -% bindTexture() optimize copied areas - - right now bindTexture() updates every damaged area and resets the window damage - - it might make things faster to update only areas that need to be repainted - and keep the rest damaged until needed - -% clipping optimization - - like XRender code has paintTransformedScreen(), avoid painting parts that are - obscured (makes a difference with many windows open) - - http://lists.kde.org/?l=kwin&m=116585618111882&w=2 - -! shm mode needs support for more data formats than GL_BGRA - - http://www.xfree86.org/current/glTexImage2D.3.html - - this now works for 16bpp, but maybe not 15bpp or less - - endian issues? - -+ support for __GL_YIELD=NOTHING and LIBGL_ALWAYS_INDIRECT should be possibly less hacky - - or at least not hardcoded (although, does that matter?) - - (http://lists.kde.org/?l=kwin&m=116439615124838&w=2) - - (http://lists.freedesktop.org/archives/xorg/2006-December/020323.html) - - -XRender TODO -============================== - -+ SceneXrender::paintTransformedScreen() doesn't handle properly extending of painted area - in window's pre-paint - see the transformedShape() comment - - and currently seems to be generally broken - - -Effects framework TODO -============================== - -* more notification functions for effects are needed - - currently there are only very few notification functions (windowAdded, windowActivated,...) -! - window state changes - ? more - -/ support for grabbing input - - during some more complicated effects, input (at least mouse) should be disabled, - because currently there is no way to do input redirection - -+ EffectWindow should be completely opaque when kept as the only API for effects - - no inlines, etc. - -+ EffectsHandler should not have virtuals but should instead use an internal object - for communication with KWin core, so that adding new functions doesn't break BC all the time - -+ API for tabbox for effects should be cleaned up - -* check Scene::updateTimeDiff() - should the time be 0 or 1? - -% post calls are probably not necessary by now (http://lists.kde.org/?t=117770818100003&r=1&w=2) - -% consider using http://lists.kde.org/?l=kwin&m=118094888517415&w=2 for notification functions - -% API cleanups and making sure it will stay backwards compatible - -Effects TODO -=============================== - -! add reloadConfig() to effects - - currently changing the global animation speed in the kcm does not change effect - -+ minimize/shade effects - - to replace the ones from KWin core -/ - minimizing - - check support for it and the avoid_animation flag -+ - shading - - shading will probably need special support - -/ zoom effect - - enlarge a portion of the screen - - Should it react to meta+wheel? - -+ logout effect -* - should be triggered by ksmserver somehow - -+ effects to replace widget effects (the ones in the Effects tab in "kcmshell style") - -/ showfps effect - - should also detect kwin being idle - it probably should detect in pre-paint that the only - damage is its own area and avoid damaging for the next round in post-paint - -/ scalein -+ - should scale in from e.g. 80%, not 0%, to just "pop up" - -+ effect for drawing attention to windows demanding attention - - Rays? Ripples? - -* DimInactive flickers when switching between windows (temporarily no window becomes active) - -- focus effect (windows waves a little when it gets focus) - -+ shadow -+ - follow the shape of the window (currently is disabled completely using the hasOwnShadow() hack) - -+ window thumbnails directly in panel - - i.e. the panel (taskbar?) could show window previews directly, without tooltips - - -Performance -================== - -+ various caching - there are many things that usually don't change and could gain few fps (is it worth it?) - - Workspace::performCompositing() - - WindowQuadList could perhaps cache quads split by contents/decoration (for select()) - -+ avoiding X roundtrips each compositing pass - - right now it at least always polls the mouse position and the current stacking order diff --git a/NEWCOLORSCHEME.README b/NEWCOLORSCHEME.README deleted file mode 100644 index ce2ca9bbda..0000000000 --- a/NEWCOLORSCHEME.README +++ /dev/null @@ -1,44 +0,0 @@ -KWin can now handle some new color scheme entries in addition to the ones -handled by KWM. Note that these are suggestions and all the colors may not -be used by all KWin styles. These all currently go into the [WM] group. - -frame, inactiveFrame : Window frame (was fixed to general KDE bg in KWM). - -handle, inactiveHandle : Window handles (sometimes called "grips"). - -activeBackground, inactiveBackground : Tilebars (bad name, but it's what KWM -uses). This is for styles that use a solid filled rectangle for the titlebar -such as the standard style and KStep. - -activeGroove, inactiveGroove: This is for titlebars that instead of a solid -rectangle use some sort of groove or small bevels layered on the frame. -An example of this is System. - -activeBlend, inactiveBlend : Titlebar blend for styles that use a rectangle -titlebar fill. - -activeForeground, inactiveForeground : Tilebar text for styles that use a -rectangle titlebar fill. - -activeGrooveText, inactiveGrooveText: Titlebar text for styles that use -grooved titlebar styles instead of the solid fill. This should contrast with -the frame color. - -activeTitleBtnBg, inactiveTitleButtonBg : Button background color for up and -down states. - -activeTitleBtnBlend, inactiveTitleBtnBlend : Button blend. - -activeTitleBtnFg, activeTitleBtnFg : Some style's buttons don't use the -above button background colors but instead draw the button foreground -transparently on the frame. The best example of this is the standard KDE -style. Use this to specify a color for such styles, which should contrast with -the frame - not the button bg. - -activeTitleBtnFullFg, inactiveTitleBtnFullFg: This is for styles that have -full support for button background settings. Examples are KStep and System. -This should contrast with the button background. - -Daniel M. Duley -mosfet@kde.org -mosfet@linuxmandrake.com diff --git a/clients/PORTING b/clients/PORTING deleted file mode 100644 index cba6ab489b..0000000000 --- a/clients/PORTING +++ /dev/null @@ -1,29 +0,0 @@ -This document lists changed needed for porting KWin decoration clients from KDE3 to KDE4: - -- the client needs to be ported to KDE4/Qt4 (obviously) -- KCommonDecoration no longer inherits KDecoration, it only has the same API (it is - source-compatible) - this means that generally there should not be any changes related - to this needed, with the exception of converting from KCommonDecoration* to KDecoration* - (most notably in createDecoration()) - call decoration() to do the conversion; - for example, change - " - KDecoration* YourClientHandler::createDecoration( KDecorationBridge* bridge ) - { - return new YourClientClient( bridge, this ); - } - " - to - " - KDecoration* YourClientHandler::createDecoration( KDecorationBridge* bridge ) - { - return ( new YourClientClient( bridge, this ))->decoration(); - } - " -- KDecoration::workspaceWidget() has been removed, for drawing outlines in drawbound(), - use code similar to example in the documentation for KDecoration::drawbound() -- KDecoration::animateMinimize() and KDecoration::helperShowHide() have been removed, - animations are now implemented only by KWin's compositing code -- there are new AbilityColor* abilities you should add to supports() -- Qt::WA_PaintOnScreen attribute is enabled for KDecoration::widget() in order to avoid - extensive and unnecessary memory usage caused by the backing store. Double-buffer - manually if necessary using a temporary QPixmap in paintEvent(). diff --git a/clients/REQUIREMENTS_FOR_CVS b/clients/REQUIREMENTS_FOR_CVS deleted file mode 100644 index 778e2fe2da..0000000000 --- a/clients/REQUIREMENTS_FOR_CVS +++ /dev/null @@ -1,20 +0,0 @@ -If you are looking to include a C++ KWin style client in CVS make sure you -follow the following requirements: - -A) You must follow the current color scheme for all decorations. *No* fixed -pixmaps are allowed for the clients. If you wish to draw your decorations -use as few shades as possible, then use kpixmap2bitmap in kdegraphics -to convert them into individual bitmaps. Once this is done you can -draw the bitmaps using a colorgroup with kColorBitmaps. - -If your client is just a set of pixmaps that doesn't follow any of the options -I suggest you make a KWM theme so the user gets those options to -configure the pixmaps and look. Making a plain pixmapped dedicated style -makes no sense since it is less configurable than KWM themes and cannot follow -client plugin options. - -B) You must follow at least the color settings in the Options class. - -Daniel M. Duley -mosfet@kde.org -