[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdebase/kwin/kompmgr
From:       Thomas =?iso-8859-9?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2005-01-15 18:44:51
Message-ID: 200501151944.52020.thomas.luebking () web ! de
[Download RAW message or body]

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!
[prev in list] [next in list] [prev in thread] [next in thread]