On Sun, 30 Jan 2005 17:08:12 +0200 Oded Arbel <[EMAIL PROTECTED]> babbled: (B (B> On Sunday, 30 __January 2005 16:55, Carsten Haitzler wrote: (B> > > > it wont work with e17. e17 will need its own compmgr. (B> (B> > > Wouldn't that cause major problems with running e17 applications (B> > > together with other applications on the same display ? can two (B> > > compmgrs run simultaneously on the same X server ? (B> > (B> > no that cant - well ok. yes they can - but thats a technicality. they (B> > are like window managers. you only really run 1. this has nothing to (B> > do with "apps" a compmanager is not an "app" its a very special x (B> > client. e17 will eventually one day provide its won compmgr built in (B> > - that means u dont (need) to run another one as its pointless. :) (B> > (B> > i suggest you read up just hos the composite extension, xdamage (B> > extension, and a windowmanager work at the lower levels and you'll be (B> > much more illuminated and know where i'm coming from. :) (B> (B> I've read a bit about those and I think I understand some of the (B> technical points of the issue, while I have no idea what you mean when (B> you say that "E17 uses virtual roots". (B> But I'm more concerned about system integration at this point: will I be (B> able to "mix and match" applications from differnet environments ? will (B> I be able to run KDE applications on an E17 desktop and have the full (B> capabilities provided by the xcompmgr for the KDE application ? (B> And how about vice versa ? will an E17 application work(*) in a KDE (B> desktop using the standard xcompmgr ? (B (Bxcompmgr is agnostic of application. it works on x client windows. it doesn't (Bcare what toolkit produced them. same with e17. it doesnt care what creates (Bthem. e17 will work with qt/gtk (gnome/kde) and other toolkit apps. we do NOT (Bplan on making "desktop environments" work under e17. that means kde's panel or (Bgnome's panel, gnome's menu bar, nautilus or konqueror filemanagers will not (Bwork on the desktop. you will find some things are already broken due to (Btoolkits not using x properly (assuming all top level windows have frame windows (Bthat are immediate children of root, not a shared virtual root). this is a basic (Bbit of BROKEN code on their part making erroneous assumptions. i intend to (Bensure its broken to get them to fix their toolkits. (B (B> (*) in both cases when I say "work", I mean not only render properly and (B> be functional: I mean the full capabilities provided by xcompmgr such (B> as transparencies. (B (Bxcompmgr wont work with e17 because it uses virtual roots. simply put u cant use (Bit at all with e17 and get anything useful out of it. a compmgr would need to be (Bbuilt INTO e17 instead. i have NO plans ton doing this until xrender ceases to (Bblow goats. (B (B> -- (B> Oded (B> (B> ::.. (B> "Once is happenstance. Twice is coincidence. Three times is enemy (B> action." (B> -- Auric Goldfinger, in "Goldfinger" / Ian L. Fleming (B> (B (B (B-- (B------------- Codito, ergo sum - "I code, therefore I am" -------------- (BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED] $BMg9%B?(B [EMAIL PROTECTED] (BTokyo, Japan ($BEl5~(B $BF|K\(B) (B (B (B------------------------------------------------------- (BThis SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting (BTool for open source databases. Create drag-&-drop reports. Save time (Bby over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. (BDownload a FREE copy at http://www.intelliview.com/go/osdn_nl (B_______________________________________________ (Benlightenment-users mailing list ([email protected] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-users
