From kde-commits Sat Jan 15 18:44:51 2005 From: Thomas =?iso-8859-9?q?L=FCbking?= Date: Sat, 15 Jan 2005 18:44:51 +0000 To: kde-commits Subject: Re: kdebase/kwin/kompmgr Message-Id: <200501151944.52020.thomas.luebking () web ! de> X-MARC-Message: https://marc.info/?l=kde-commits&m=110581476628449 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) Thomas -- Think, think different. But essentially: Think!