[gentoo-amd64] KDE: dispappearing window frames and titlebar

[gentoo-amd64] KDE: dispappearing window frames and titlebar

[Albert]

Hello,

a strange problem shows up since yesterday in KDE (3.4). I run ~amd64.
My window frames and titlebars do not show up anymore when I log into KDE. I 
had selected "glow" as decoration theme.

Also, although I had not changed the quantity of desktops from the default 4, 
it now shows only one.

Any help will be appreciated, or is it time to switch to enlightenment :-) ?

Albert
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: KDE: dispappearing window frames and titlebar

[Duncan]

Albert posted <200510271913.23101.nixul@free.fr>, excerpted below,  on
Thu, 27 Oct 2005 19:13:23 +0200:

> a strange problem shows up since yesterday in KDE (3.4). I run ~amd64. My
> window frames and titlebars do not show up anymore when I log into KDE. I
> had selected "glow" as decoration theme.

That means kwin is either not being started (unlikely) or is crashing
(more likely, particularly since it happened in connection with setting
glow).

Glow has a component that "glows" the titlebar buttons as you move over
them.  This is a dynamic feature that would require a compiled solution to
do the "glowing".  Apparently, when you compiled, this portion miscompiled
somehow, likely due to a CFLAG (CXXFLAG in this case) incompatibility that
hasn't been caught and filtered for yet.

Consequently, the ultimate fix would be to recompile/remerge the
appropriate styles package (kde-base/kdeartwork-kwin-styles, here, using
the split-packages option, thus kdeartwork if not), probably being a bit
more conservative with your CXXFLAGS setting.

However, you should be able to simply reconfigure KDE to use something
other than the "glow" style, and then restart kwin, and it should work
just fine.

The "kill them all and let God sort them out" method would be to simply
wipe your entire ~/.kde (or ~/.kde3.4 or whatever) dir, but if you are
like me, you customize FAR to much to be comfortable simply blowing it
away and starting over.

Thus, the generic method I've reliably used under such circumstances has
been "process of elimination".  First, I rename the entire config dir in
question, and restart whatever (KDE in this case) to see if it starts
without my customized config.  An alternative to this is to have a "test"
user setup that's generic/uncustomized.  You can then simply login as this
user and see if it works, which it should.

Assuming the above confirms it's in the old custom config, I create a
second copy, so I have the one it's trying to use and a backup, then dive
into the (non-)working copy it'll use and take a look around for likely
subdirs (or files) to delete (keeping in mind I still have the backup copy
so nothing's getting permanently destroyed).  Depending on whether I can
make an intelligent guess as to where the problem is or not, I either
delete the guessed problem dir, or roughly half the config.  Then I try
booting that and see if it works or not.  If not, I try the other half or
look for a different suspect candidate.

After I've confirmed a suspect, I copy everything over from the backup
again, and do the same with the new, now smaller, suspect, each time
taking either half the remaining config or a likely suspect.

Eventually I'm down to a single culprit file.  At that point, one could
probably simply reconfigure whatever's in that file, but I'm the type that
likes to trace the problem as far as possible, so I'll usually open said
file for editing and use the same techniques as above with the sections I
find inside, deleting either roughly half the remaining culprit config, or
a specific suspect section, until I trace the issue to a single section.

Then I do the same thing with individual lines within the config section
within the file.  By the time I'm finished, I usually have a specific
config option that caused my problem, and know enough either not to try
that combination of options again, or to file a bug if I don't think it
was something specific to my config (like the fact I'm currently running
the still masked gcc-4.0.2 and an associated still-masked binutils and
glibc, so if it looks to be CFLAGS related, I better try recompiling with
gcc-3.4.x before filing a bug).

However, since I run KDE and have done this process a couple times, enough
to make an educated guess as to where the config issue is, I can probably
save you a couple of those elimination iteration steps...

The problem will almost certainly be under ~/.kde[ver]/share/, in either
config/<appname>*rc (thus kwinrc or kwin-something-rc), or in a
file under apps/<appname>/*

Restated, your two candidates for initial process of elimination deletion
are ~/.kde[ver]/share/config/kwin* and
~/.kde[ver]/share/apps/kwin/*.  After making a backup, try wiping one
or the other and restarting KDE.  If that fixes it, restore the wiped
config from the backup and delve into it further.  If not, try the other
one.

> Also, although I had not changed the quantity of desktops from the default
> 4, it now shows only one.

I'm not sure if this is a function of kwin or not, but given the above is
certainly a kwin crash, this is probably related, so fixing kwin as above
should fix this as well.

Not so difficult when you know what to do to fix it, is it?  <g>

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list