> Just my observations with Slackware
> 13.1. YMMV. Please feel free to add, edit, qualify, add a
> workaround, etc.
>
> Should we fine tune this information and post to our wiki?
>
> ===================================
>
> Whereas the Trinity developers have worked hard to support
> KDE 4 compatibility, there are several challenges with
> running Trinity, KDE 4, and KDE 3 installed on the same
> multiple user system.
>
> 1. Many of the apps use the same file name. The scripts in
> /etc/profile.d produce conflicting file search paths.
> Without the appropriate file search path, the file search
> path highest in the path hierarchy will launch the app,
> which might not be the correct app.
>
> 2. On multiple user systems, the profile.d scripts can’t
> be arbitrarily disabled because any of the desktop
> environments might be used.
>
> 3. The profile.d scripts cause conflicts with XDG paths,
> which create the desktop menus. Normally this is not a
> problem with other desktops such as Xfce, but that is not
> the case with these three desktops because many apps have
> the same name. With each profile.d script being sourced,
> each desktop system menu will show every app from all other
> desktops. The Trinity developers have hacked a neat trick to
> tag the KDE 4 apps in the menu, but there is no such support
> for KDE 3 apps. The hack does not exist for KDE 4 or KDE 3.
>
> 4. User-defined menu changes are stored in
> $HOME/.config/menus and $HOME/.local/applications. As those
> directories are global to anything the user does, menu
> changes in one desktop affects the other desktops if a user
> wants to change desktops. That means conflicts with starting
> apps.
>
> 5. The KDE 3 and Trinity KDM login manager will conflict
> unless one or the other is disabled (chmod -x). Neither can
> be used to support the other desktops because of the
> underlying dependency on each desktop’s respective kdelibs
> package.
>
> 6. The file search path conflicts will introduce multiple
> autostart directories. Apps in those directories will start
> for the other desktops too.
>
> A possible work-around to most of these conflicts is to
> disable all affected profile.d scripts and then modify the
> xinitrc scripts to source the appropriate profile.d scripts.
> That might suffice for run level 3, but not run level 4. Run
> level 4 would require some detailed scripting in the KDM
> Xsession script to look at the user’s dmrc config file and
> then source the appropriate profile.d scripts. Yet these
> work-around won’t resolve any user-defined menu changes.
>
> On single user systems or systems where all users want to
> use the same desktop, all of this can be avoided by
> uninstalling the other desktop environments.
>
> ===================================