The ebuilds for >=xchat-1.9 will compile in gtk-2 support if the gtk use variable is set not the gtk2 variable. If the user only has gtk2 use variable no GUI will be compiled for xchat.
Read /usr/portage/profiles/use.desc : gtk2 - use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. gtk2 is only there for apps who support both in one release.
*** Bug 17670 has been marked as a duplicate of this bug. ***
Just my two cents on this: I think this behavior is somewhat intransparent for the casual user who very likely understands it the way I did: gtk for gtk1 and gtk2 for gtk2 support - which is rather logical. Now since xchat only supports gtk2, you have to specify "gtk" again to get gtk2 support... that's quite strange. I for one don't want any legacy gtk1 programs here, so I explicitly did "gtk2 -gtk". Naturally my approach raises the problem: what if "gtk gtk2" is set... basically use the newer of both if it's supported otherwise fallback to gtk1... Maybe we could reopen this for discussion?
no, perhaps we could clarify the use.desc in this case, but the gtk2 flag is transiental, and will hopefully be phased out in a short while as gtk2 UI's stabilize enough for the applications to release the gtk2 branch only. The behaviour you see is because you are supposed to not get a UI at all if you use -gtk gtk2, in a proper setting theese two are nested, and you won't get gtk2 or gtk1 support with that combination. the check is supposed to be a hierarchy of begin if gtk then if gtk2 then enable gtk2 else enable gtk end; Which will affirm that the gtk flag does what it is supposed to do.
Ok... with that explanation in mind, things do sound logical again. :-) And I didn't know that it's basically a transiental solution. Yet I do agree, updating the use.desc would be a good idea. Luckily for me, in most cases, the gtk/gtk2 use flag detection is *not* nested in those ebuilds... otherwise everything else would have been built without an optional ui... ;-)
there are very few packages that have optional UIs.
