| 1 |
Albert posted <200510271913.23101.nixul@××××.fr>, excerpted below, on |
| 2 |
Thu, 27 Oct 2005 19:13:23 +0200: |
| 3 |
|
| 4 |
> a strange problem shows up since yesterday in KDE (3.4). I run ~amd64. My |
| 5 |
> window frames and titlebars do not show up anymore when I log into KDE. I |
| 6 |
> had selected "glow" as decoration theme. |
| 7 |
|
| 8 |
That means kwin is either not being started (unlikely) or is crashing |
| 9 |
(more likely, particularly since it happened in connection with setting |
| 10 |
glow). |
| 11 |
|
| 12 |
Glow has a component that "glows" the titlebar buttons as you move over |
| 13 |
them. This is a dynamic feature that would require a compiled solution to |
| 14 |
do the "glowing". Apparently, when you compiled, this portion miscompiled |
| 15 |
somehow, likely due to a CFLAG (CXXFLAG in this case) incompatibility that |
| 16 |
hasn't been caught and filtered for yet. |
| 17 |
|
| 18 |
Consequently, the ultimate fix would be to recompile/remerge the |
| 19 |
appropriate styles package (kde-base/kdeartwork-kwin-styles, here, using |
| 20 |
the split-packages option, thus kdeartwork if not), probably being a bit |
| 21 |
more conservative with your CXXFLAGS setting. |
| 22 |
|
| 23 |
However, you should be able to simply reconfigure KDE to use something |
| 24 |
other than the "glow" style, and then restart kwin, and it should work |
| 25 |
just fine. |
| 26 |
|
| 27 |
The "kill them all and let God sort them out" method would be to simply |
| 28 |
wipe your entire ~/.kde (or ~/.kde3.4 or whatever) dir, but if you are |
| 29 |
like me, you customize FAR to much to be comfortable simply blowing it |
| 30 |
away and starting over. |
| 31 |
|
| 32 |
Thus, the generic method I've reliably used under such circumstances has |
| 33 |
been "process of elimination". First, I rename the entire config dir in |
| 34 |
question, and restart whatever (KDE in this case) to see if it starts |
| 35 |
without my customized config. An alternative to this is to have a "test" |
| 36 |
user setup that's generic/uncustomized. You can then simply login as this |
| 37 |
user and see if it works, which it should. |
| 38 |
|
| 39 |
Assuming the above confirms it's in the old custom config, I create a |
| 40 |
second copy, so I have the one it's trying to use and a backup, then dive |
| 41 |
into the (non-)working copy it'll use and take a look around for likely |
| 42 |
subdirs (or files) to delete (keeping in mind I still have the backup copy |
| 43 |
so nothing's getting permanently destroyed). Depending on whether I can |
| 44 |
make an intelligent guess as to where the problem is or not, I either |
| 45 |
delete the guessed problem dir, or roughly half the config. Then I try |
| 46 |
booting that and see if it works or not. If not, I try the other half or |
| 47 |
look for a different suspect candidate. |
| 48 |
|
| 49 |
After I've confirmed a suspect, I copy everything over from the backup |
| 50 |
again, and do the same with the new, now smaller, suspect, each time |
| 51 |
taking either half the remaining config or a likely suspect. |
| 52 |
|
| 53 |
Eventually I'm down to a single culprit file. At that point, one could |
| 54 |
probably simply reconfigure whatever's in that file, but I'm the type that |
| 55 |
likes to trace the problem as far as possible, so I'll usually open said |
| 56 |
file for editing and use the same techniques as above with the sections I |
| 57 |
find inside, deleting either roughly half the remaining culprit config, or |
| 58 |
a specific suspect section, until I trace the issue to a single section. |
| 59 |
|
| 60 |
Then I do the same thing with individual lines within the config section |
| 61 |
within the file. By the time I'm finished, I usually have a specific |
| 62 |
config option that caused my problem, and know enough either not to try |
| 63 |
that combination of options again, or to file a bug if I don't think it |
| 64 |
was something specific to my config (like the fact I'm currently running |
| 65 |
the still masked gcc-4.0.2 and an associated still-masked binutils and |
| 66 |
glibc, so if it looks to be CFLAGS related, I better try recompiling with |
| 67 |
gcc-3.4.x before filing a bug). |
| 68 |
|
| 69 |
However, since I run KDE and have done this process a couple times, enough |
| 70 |
to make an educated guess as to where the config issue is, I can probably |
| 71 |
save you a couple of those elimination iteration steps... |
| 72 |
|
| 73 |
The problem will almost certainly be under ~/.kde[ver]/share/, in either |
| 74 |
config/<appname>*rc (thus kwinrc or kwin-something-rc), or in a |
| 75 |
file under apps/<appname>/* |
| 76 |
|
| 77 |
Restated, your two candidates for initial process of elimination deletion |
| 78 |
are ~/.kde[ver]/share/config/kwin* and |
| 79 |
~/.kde[ver]/share/apps/kwin/*. After making a backup, try wiping one |
| 80 |
or the other and restarting KDE. If that fixes it, restore the wiped |
| 81 |
config from the backup and delve into it further. If not, try the other |
| 82 |
one. |
| 83 |
|
| 84 |
> Also, although I had not changed the quantity of desktops from the default |
| 85 |
> 4, it now shows only one. |
| 86 |
|
| 87 |
I'm not sure if this is a function of kwin or not, but given the above is |
| 88 |
certainly a kwin crash, this is probably related, so fixing kwin as above |
| 89 |
should fix this as well. |
| 90 |
|
| 91 |
Not so difficult when you know what to do to fix it, is it? <g> |
| 92 |
|
| 93 |
-- |
| 94 |
Duncan - List replies preferred. No HTML msgs. |
| 95 |
"Every nonfree program has a lord, a master -- |
| 96 |
and if you use the program, he is your master." Richard Stallman in |
| 97 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 98 |
|
| 99 |
|
| 100 |
-- |
| 101 |
gentoo-amd64@g.o mailing list |
Archives