Re: [trinity-devel] Running Trinity, KDE 4, and KDE 3 Concurrently

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. ===================================