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