I run KDE here, don't even have GNOME installed as for me as a power user, GNOME's dumb-down-everything-by-removing-most-choices-as-too- complex policy drives me right up one wall and down the other! (I'm with Linus on that one, it seems!) I'm running kwin, with composite functionality enabled (only window semi-transparency, not the other stuff) as I mentioned above.
Never could get over the UI, didn't seem intuitive to me for whatever reason. Been following KDE 4 development, look pretty spiffy. Probably give it a shot again once it goes alpha. Could be mistaken but it almost seems like the gnome folk are more concerned about their release schedule than innovating new features.
Anyway, this build doesn't have the patches applied, and exa works fine once again.
I think an exa update was one of the main additions in 1.3, the other being the randr 1.2 code.
If you've not already done so and the lack of gnome-terminal is serious for you, of course there are quite a few other alternatives, xterm being the generic one, naturally. Thinking about your bug, perhaps you have the reverse problem to mine, as konsole (compare to gnome-terminal) did run here but as I said, with issues (blanking and the like). You might dig out the AIGLX patches from 1.2.0-r1 and see if they still apply cleanly to 1.2.99.901. If they do, try that and see if your problem still exists. Take a look at the ebuild but I /think/ all you have to do is list the appropriate patches in a PATCHES= line, copying the ones from the line in the ~arch version to .901 in your overlay. A single bit of editing, not too hard. (I was going to try building without those patches here, but never got around to it before seeing your post mentioning the new version, so tried it instead.) If that fixes your problem, then it's likely those patches may have to be hooked to a USE flag of some sort, so people can apply them or not depending on the hardware and software they run. Something else that /might/ be worth trying. Enable (or disable, if you have it enabled) USE=xcb, and do an emerge -N world to rebuild anything using that flag. xcb is a new and lighter alternative to Xlib. Xlib can render to it for anything not yet migrated to xcb yet, and that's what most X clients are using if xcb is enabled at this point, xlib thru xcb. I decided to try enabling it at the same time I upgraded to xorg-server 1.2.99.901, and one of the things that got rebuilt as a result was cairo, which of course is what GTK+ now uses for rendering, and GNOME of course in turn uses GTK+. (I do have GTK+ merged, as a pan dependency, but no GNOME.) What I'm thinking is that xcb might bypass whatever issue you are having, particularly if it's a deprecated xlib call that's no longer working, since xcb is newer and presumably written with AIGLX and similar new technologies in mind, where xlib has a lot of compatibility cruft left over from long ago versions. I've seen the difference that makes in xaa/ exa, xlib/xcb could well make a similar difference. So anyway, please update if you try any of the suggestions above, whether or not they work, or if you get it working again otherwise. I'm always interested in finding out if my guesses were correct or not, as it's very useful info the next time something similar comes up.
A couple of emerge -e world's later.... metacity - gnome-terminal starts fine, <CTRL><SHIFT>T creates a new tab beryl - gnome-terminal starts fine, <CTRL><SHIFT>T crashes it as before I'll chalk this one up to either stupidity on my part or the beryl svn code I'm using is conflicting with the new driver / server code. No big, some breakage is to be expected running ~arch & live code. FWIW, I'm using XAA and have xcb enabled. EXA makes little difference on my system, haven't had a chance to see what recompiling w/out xcb will do. The next rc build should be hitting portage soon, I'll probably just wait & see if that does some magic. Or breaks more stuff =) Wil -- [email protected] mailing list
