On Sun, 30 Jan 2005 17:08:12 +0200 Oded Arbel <oded-e@...> babbled:
> On Sunday, 30 __January 2005 16:55, Carsten Haitzler wrote:
> > > > it wont work with e17. e17 will need its own compmgr.
> > > Wouldn't that cause major problems with running e17 applications
> > > together with other applications on the same display ? can two
> > > compmgrs run simultaneously on the same X server ?
> > no that cant - well ok. yes they can - but thats a technicality. they
> > are like window managers. you only really run 1. this has nothing to
> > do with "apps" a compmanager is not an "app" its a very special x
> > client. e17 will eventually one day provide its won compmgr built in
> > - that means u dont (need) to run another one as its pointless. :)
> > i suggest you read up just hos the composite extension, xdamage
> > extension, and a windowmanager work at the lower levels and you'll be
> > much more illuminated and know where i'm coming from. :)
> I've read a bit about those and I think I understand some of the
> technical points of the issue, while I have no idea what you mean when
> you say that "E17 uses virtual roots".
> But I'm more concerned about system integration at this point: will I be
> able to "mix and match" applications from differnet environments ? will
> I be able to run KDE applications on an E17 desktop and have the full
> capabilities provided by the xcompmgr for the KDE application ?
> And how about vice versa ? will an E17 application work(*) in a KDE
> desktop using the standard xcompmgr ?
xcompmgr is agnostic of application. it works on x client windows. it doesn't
care what toolkit produced them. same with e17. it doesnt care what creates
them. e17 will work with qt/gtk (gnome/kde) and other toolkit apps. we do NOT
plan on making "desktop environments" work under e17. that means kde's panel or
gnome's panel, gnome's menu bar, nautilus or konqueror filemanagers will not
work on the desktop. you will find some things are already broken due to
toolkits not using x properly (assuming all top level windows have frame windows
that are immediate children of root, not a shared virtual root). this is a basic
bit of BROKEN code on their part making erroneous assumptions. i intend to
ensure its broken to get them to fix their toolkits.
> (*) in both cases when I say "work", I mean not only render properly and
> be functional: I mean the full capabilities provided by xcompmgr such
> as transparencies.
xcompmgr wont work with e17 because it uses virtual roots. simply put u cant use
it at all with e17 and get anything useful out of it. a compmgr would need to be
built INTO e17 instead. i have NO plans ton doing this until xrender ceases to
> "Once is happenstance. Twice is coincidence. Three times is enemy
> -- Auric Goldfinger, in "Goldfinger" / Ian L. Fleming
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
Tokyo, Japan (東京 日本)