Tuomo Valkonen wrote: >On Fri, Jun 27, 2003 at 12:14:29PM +0100, Sam Mason wrote: >> It seems to work in my version of X. ION doesn't cooperate too well >> with it for some reason. I think it's because it unmap's windows when >> they're not on top of the stack. This causes the translucent window >> to draw on top of a black window sometimes - rather than the window's >> that are beneath it in the stack. > >Under TWM [. . . stuff cut ]
Yup, the text I read suggested to me that it could do what I thought it wanted. I played around with it some more; and came to the same conclusion as you. The transparency is nothing more than a horrendous hack in Xft. >At least I could not find an Xrender function to set window translucency, >only the alpha of drawing operations and how "pictures" are combined with >the screen. (But what little Xrender documentation I've found is bad.) I wouldn't say that I've had a particularly extensive search; but I haven't turned up anything as well. But it all seems rather annoying, considering all the work that went into Xrender. >I see no reason why X couldn't >support proper window translucency or even translucent primitive drawing >operations without duplicating them in e.g. Xrender.) I couldn't comment on the right place to put them - but translucent primitives could be easily incorporated into the X framework. I would argue against putting them into the core protocol because that would break every other X implementation out there. But, "window level" transparency extension, could be designed that would expose the relevant details to the client. It goes without saying, that when using this extension, all the existing primitives should continue to work as expected. Sam
