Message: previous - next
Month: December 2011

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

From: Darrell Anderson <humanreadable@...>
Date: Tue, 6 Dec 2011 10:42:39 -0800 (PST)
> 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.
> ===================================

Does anybody have anything to add to these observations?

To confirm?

To dispute?

I will add another item to the list: migrating KMail files from KDE3 to TDE changes the index files. The change is non-destructive, annoying only, but KMail complains if a person tries to use KMail in both environments. Users can run KMail in either but must manually reindex all of the files each time.