Right.  We've never done it by default, and it's one of those things which are just part of the unwritten API.  It would pretty spectacularly break most apps using a toolkit, so why not just have GTK actually look at the list of visuals and take an RGBA visual, given that it can handle RGBA?

(In reply to comment #1)
> Right.  We've never done it by default, and it's one of those things which are
> just part of the unwritten API.  It would pretty spectacularly break most apps
> using a toolkit, so why not just have GTK actually look at the list of visuals
> and take an RGBA visual, given that it can handle RGBA?
> 
Yes, this could be done. We were just wondering *why* it returns always RGB, even with supported cards.

By the way, from my point of view, should be better to return the correct colormap supported, and, if a toolkit is broken with RGBA should be the toolkit to force RGB usage.

If, for example, tcl/tk, fox toolkit etc etc don't support RGBA colormap then should be not a Xorg problem (so forcing Xorg to use *always* RGB) but a toolkit bug.

From your reply it seems like Xorg development is limited by buggied toolkits (in the meaning they will crash with RGBA).

(In reply to comment #2)
> Yes, this could be done. We were just wondering *why* it returns always RGB,
> even with supported cards.

As someone noted before, people are relying on just being able to fill with all 0s.  X doesn't note anything about alpha: it's only a recent Render innovation.

> By the way, from my point of view, should be better to return the correct
> colormap supported, and, if a toolkit is broken with RGBA should be the toolkit
> to force RGB usage.

That would be nice, but it's very little work to actually go through the visual list.  If you want alpha to be supported, why not just look for an alpha visual instead of taking the default? You mention buggy toolkits relying on undocumented behaviour -- well, this is an example right here.

> If, for example, tcl/tk, fox toolkit etc etc don't support RGBA colormap then
> should be not a Xorg problem (so forcing Xorg to use *always* RGB) but a
> toolkit bug.

They should be fixed, but strictly speaking, there's nothing in the core spec about RGBA: it's purely an extension thing.

> From your reply it seems like Xorg development is limited by buggied toolkits
> (in the meaning they will crash with RGBA).

Not crash, just render incorrectly.

I just find it odd that you're passionately arguing that we should change behaviour to something arguably non-conformant and that every app (it's not just toolkits: apps too) should change everything to scan the visual list and explicitly look at all components, given that the entire reason you're saying this is to avoid doing the very same behaviour with GTK ...

I agree with you that scanning the visual list and picking the 'best' one is the right thing to do here, which is why, when the choice comes down to fixing GTK to do the right thing, and help out explicitly alpha-aware users (of which there aren't that many: mainly just GTK and Cairo); or helping GTK work on some systems by accident, and breaking apps that are actually just conforming to the spec.

I'm pretty sure it was a conscious decision to ensure apps had to explicitly request an alpha visual, and IMO it's a good one.

What about adding a config option to xorg.conf that had this effect?

To comment on Benjamins idea, it will allow the bleeding-edge lot to get these new features with ease, and therefore start paving the way for this new UI stuff. Also , it'll provide a nice way to test existing toolkits/applications (and hopefully fix them if they don't work).