On Saturday 15 January 2005 18:56, Ismail Donmez wrote:
> Some questions. Why don't you use fredrik's kcompmgr code?

afaik the kcompmgr code is intended to be (internal) part of kwin, while the current kompmgr is a fork of the original xcompmgr that resides as standalone process and is (only if activatedwished) just handled by kwin. also lubos mentioned that fredrik's code won't be done for 3.4 and so we're (temporary) going this direction until there's a internal compmgr for kwin.

as you mentioned: XComposite is far from being bugfree/perfectly supported (e.g. no gtk 1.x app works really good with XCompositeRedirect()). so this is just a (very optional) option to play around if you wish eyecandy (there're warning dialogs everywhere telling you that this is not considered to be code for productive environments)

the whole thing is discussed with lubos and fredrik (see the kwin delevoper list) and does not really touch kwin itself too much (process startup and dynamic setting of some X properties, i assime parts of the config code can/will be reused later)

in matters of what does _not_ work with the Composite extension: i'd suggest to open a list to entry critical candidates, use of XComposite/compmgrs in general (e.g. ati users should currently keep away from that)

So instead of using Fredrik's awesome kcompmgr you essentially forked Keith's xcompmgr and will be integrating it in KWin? That sucks...

Please read the discussion on the kwin developer list. kompmgr is a standalone process, only handled by kwin for kde3.4
fredriks code is not gonna be ready before kde4.0 (3.5? :) therefore we take this as (quite temporary) solution