window manager - Is there a way to stop KDE from overwriting my other WM settings?

What is the problem?

• KDE does not respect other window manager/DE settings.

  
  
  
  

  Is there a way to safely run KDE alongside other window managers without having to reconfigure them every time after finishing my testing with KDE?

Background

My user's main desktops are primarily xfce (4.6, 4.8, 4.10) and Unity.

• I frequently test multiple Window Managers(fluxbox, enlightenment, unity, gnome, etc). Only KDE causes me problems when returning to another WM once I am done testing some KDE functionality.

What I have done to fix this?

When returning to a WM other than KDE, I find that I have to delete config(specifically *gtk files) files in order to return my other WM's to their default settings.

What answer am I looking for?

• Are there any file permissions that I can set to prevent KDE from breaking my other WM settings?



• Is there a way to determine what files in my home directory that KDE touches and modifies? That might help my narrow down my issue.


• I am amenable to building a login script to correct anything that KDE has broken. For three users, this would be acceptable. This doesn't scale to 50 users.

What can I do to safely test KDE and return to my default window manager without having to continually restore my configuration?

Why is this important?

Here is a use-case that is causing me problems:

I have a user(think C-level exec) that likes to change back and forth between KDE and xfce(among other WMs). How can I configure their profile so they do not get KDE window decorations when they decide to move back to xfce?

As it stands, I have been unable to prevent an xfce session from being totally mangled after a user logged into a KDE session.

Here is a solution that I have found mitigate display/window decoration issues when switching between KDE and Xfce.

How do I find which files KDE has modified?

Finding the files that have changed in a home directory, within a specified time period, is fairly straightforward.

find ~ -maxdepth 5 -mmin 10 (searches for changes within the last 10 minutes)

However, the results are cluttered with a large number of dynamic files(various app caches, for example). So, I needed to exclude those from my results:

find ~/ -maxdepth 5 \( -path ~/.cache -o -path ~/.xchat2 -o -path ~/.local -o -path ~/Downloads -o -path ~/.config/deluge -o -path ~/.config/chromium -o -path ~/docs -o -path ~/.dropbox -o -path ~/Dropbox -o -path ~/.pulse -o -path ~/.dbus \) -prune -o -mmin -5

This results in a much more manageable list to identify the files KDE has modified(I don't doubt that there is a more elegant solution to get the same results).

What files need to be changed and what commands should be run?

Prior to exiting KDE, enter a terminal(Ctrl-Alt-t), and enter the following command:

rm ~/.gtkrc-2.0

This will remove KDE window decoration settings and its deletion will result in those settings not being applied to Xfce. However, once logged into Xfce, the WM will need to be reset with the following command:

xfwm4 --replace

Additionally, if any theme or font changes have been made while working in KDE, another file will need to be deleted prior to logging into Xfce. Otherwise, fonts in the web browser will have been modified.

Again, from the command line:

rm ~/.fonts.conf

How can I (partially) automate this?

I have automated part of this by editing /etc/lightdm/lightdm.conf and placing the following lines in the file:

    [SeatDefaults]
    session-cleanup-script = home//clean_up_after_kde.sh 

The script contains the two rm commands from above. The xfwm --replace cannot run until the desktop environment has already started, so this is still run manually.

In order for the changes to take effect, lightdm needs to be restarted. Run the following:

sudo restart lightdm.

Your session will immediately restart after this command and drop you back to a login screen, so ensure that you have saved any work before restarting.

These commands will be run as part of the logout process now. Note that this script runs only after the user is completely logged out.

While this is still pretty kludgey, it is a smaller step to making it less so.