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.
===================================
Darrell
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.
- 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.
- On multiple user systems, the profile.d scripts can’t
be arbitrarily disabled because any of the desktop environments might be used.
- 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.
- 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.
- 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.
- 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.
Darrell
On 6 December 2011 13:42, Darrell Anderson humanreadable@yahoo.com wrote:
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.
- 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.
- On multiple user systems, the profile.d scripts can’t
be arbitrarily disabled because any of the desktop environments might be used.
- 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.
- 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.
- 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.
- 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.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Do we want to bother with making sure KDE3/Trinity can sit on the same PC? KDE
On 6 December 2011 14:33, Calvin Morrison mutantturkey@gmail.com wrote:
On 6 December 2011 13:42, Darrell Anderson humanreadable@yahoo.comwrote:
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.
- 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.
- On multiple user systems, the profile.d scripts can’t
be arbitrarily disabled because any of the desktop environments might be used.
- 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.
- 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.
- 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.
- 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.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Do we want to bother with making sure KDE3/Trinity can sit on the same PC? KDE
Sorry,
this new gmail interface is rather annoying and cuts my emails off frequently. I think KDE4 is a higher priority.
We could change file names. Especially during our renaming process. I don't feel that Tonsole (sounds like a body part hehe) would work, we could rename it konsole-trinity or tkonsole? for other apps though, it could be smooth. Tsysguard T3B, TMail TAlarm... etc
Le Tue, 6 Dec 2011 14:36:31 -0500, Calvin Morrison mutantturkey@gmail.com a écrit :
Do we want to bother with making sure KDE3/Trinity can sit on the same PC? KDE
Sorry,
this new gmail interface is rather annoying and cuts my emails off frequently. I think KDE4 is a higher priority.
We could change file names. Especially during our renaming process. I don't feel that Tonsole (sounds like a body part hehe) would work, we could rename it konsole-trinity or tkonsole? for other apps though, it could be smooth. Tsysguard T3B, TMail TAlarm... etc
This still will cause pain for people coming from KDE3 and who are used to run programs by Alt-F2 or command-line. I think different installation prefixes are the only sane solution for Trinity/KDE4 cohabitation, and therefore f*** off Fedora and their put-everything-on-Program Files^W^W/usr crap.
On 6 December 2011 14:46, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
Le Tue, 6 Dec 2011 14:36:31 -0500, Calvin Morrison mutantturkey@gmail.com a écrit :
Do we want to bother with making sure KDE3/Trinity can sit on the same PC? KDE
Sorry,
this new gmail interface is rather annoying and cuts my emails off frequently. I think KDE4 is a higher priority.
We could change file names. Especially during our renaming process. I don't feel that Tonsole (sounds like a body part hehe) would work, we could rename it konsole-trinity or tkonsole? for other apps though, it could be smooth. Tsysguard T3B, TMail TAlarm... etc
This still will cause pain for people coming from KDE3 and who are used to run programs by Alt-F2 or command-line. I think different installation prefixes are the only sane solution for Trinity/KDE4 cohabitation, and therefore f*** off Fedora and their put-everything-on-Program Files^W^W/usr crap.
There are always growing pains :-)
On 6 December 2011 14:46, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
Le Tue, 6 Dec 2011 14:36:31 -0500, Calvin Morrison mutantturkey@gmail.com a écrit :
Do we want to bother with making sure KDE3/Trinity can sit on the same PC? KDE
Sorry,
this new gmail interface is rather annoying and cuts my emails off frequently. I think KDE4 is a higher priority.
We could change file names. Especially during our renaming process. I don't feel that Tonsole (sounds like a body part hehe) would work, we could rename it konsole-trinity or tkonsole? for other apps though, it could be smooth. Tsysguard T3B, TMail TAlarm... etc
This still will cause pain for people coming from KDE3 and who are used to run programs by Alt-F2 or command-line. I think different installation prefixes are the only sane solution for Trinity/KDE4 cohabitation, and therefore f*** off Fedora and their put-everything-on-Program Files^W^W/usr crap.
There are always growing pains :-)
Not going to rename those applications unless I have to for legal reasons. There is such a thing as deadly pain (too much change for no benefit) ;-)
Tim
There are always growing pains :-)
Not going to rename those applications unless I have to for legal reasons.
There is such a thing as deadly pain (too much change for no benefit) ;-)
I'm glad there will not be a blanket "brain-dead" renaming policy. A reasonable renaming effort is sufficient.
Possibly there is a fine line between embracing a TDE personality and maintaining roots to the original KDE3 heritage. In that respect I suspect the main future challenge is to remain focused on our project and not get suckered into KDE4 bashing. :) Whenever TDE gets compared to KDE4 and the writer starts bashing KDE4, then the KDE4 fans come out of the woodwork.
I have been watching the patches list. Tim is doing a fine job with rebranding. Sufficiently that R14 will indeed be TDE and not the "former KDE3." :)
Darrell
Do we want to bother with making sure KDE3/Trinity can
sit on the same PC?
KDE
No.
Do we want to support running both concurrently? I agree, no. Yet there is one important reason to run both: KDE3 remains the baseline to which we know when TDE is working incorrectly. For example, my recent threads and bug reports about the Kaffeine DVB OSD.
A check list of cautions will help people run both in order to use that baseline for testing.
Currently I am dual booting KDE3 and TDE with mirror partitions of my base Slackware 13.1. Dual booting is, um, annoying. I have a couple of user accounts dedicated to testing. Installing TDE on my primary system would allow me to test under the exact same conditions without rebooting. I have a virtual machine with TDE installed, but I can't test everything there --- such as the video issues I discovered with the proprietary Nvidia drivers.
I need to run both with reasonable safety. Hence my desire to encourage some conversation about the topic.
I think there is no problem with the packages as I built everything with a $PREFIX of /opt/trinity. To avoid environment variable conflicts, I can write some snippets in my testing account's .bashrc to test when to remove KDE3 or TDE environment variables that get sourced from /etc/profile.d. As a testing account I can avoid conflicts with ~/.local by not modifying the menu and so forth.
My testing account does not use KMail. I login in from the command line and therefore would avoid conflicts with differing KDMs.
I have not migrated completely to TDE because until recently, several significant bugs had remained unresolved from before 3.5.12. Fortunately, recently I found solutions for most and have submitted patches.
Yet I'm the slow and cautious type. :) The other day I considered moving to TDE full time and then I run into more bugs like the Kaffeine DVB OSD glitches, the Nvidia driver conflict, and of late, my inability to build KOffice.
I use KMail with my primary user account and won't migrate that account to TDE until I'm comfortable I have the other significant bugs out of my way because as I mentioned, the indexes in KMail get reworked in TDE. Although I can back out of the KMail reindexing, doing so is a nuisance. :)
A check list of cautions is needed to avoid conflicts with KDE4. For example, I don't know how to avoid both environments from conflicting because both use ~/.local. I have not done any testing, but I wonder what happens when TDE KDM is used rather than KDE4 KDM. I suspect using the TDE KDM to run KDE3 will cause problems.
I admit I don't test for KDE4 conflicts because, um, well, I stripped KDE4 from my system. :) I did that last year when I rebuilt KDE3 to run on Slackware 13.1, and now that I am close to moving to TDE, despite building all packages for /opt/trinity, I have no real desire to install any KDE4 packages. I really do like the KDE3/TDE environment and that is why I am involved here. :)
Darrell
A check list of cautions will help people run both in order to use that baseline for testing.
Currently I am dual booting KDE3 and TDE with mirror partitions of my base Slackware 13.1. Dual booting is, um, annoying. I have a couple of user accounts dedicated to testing. Installing TDE on my primary system would allow me to test under the exact same conditions without rebooting. I have a virtual machine with TDE installed, but I can't test everything there --- such as the video issues I discovered with the proprietary Nvidia drivers.
I need to run both with reasonable safety. Hence my desire to encourage some conversation about the topic.
Let me throw a question out to you coders:
Installing TDE alongside KDE should not be a problem with both using different a $PREFIX.
Will running both concurrently cause conflicts because the various app names and libraries use the same name?
That is, will be able to run one user account in KDE3 and another in TDE? Or will all accounts need to exit the desktop before running the other desktop? Or will be there no conflict because each environment is linked to different locations.
Having all accounts exit is a tad better than rebooting, but only a tad. :)
Opinions?
Darrell
Le Tue, 6 Dec 2011 12:50:07 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
A check list of cautions will help people run both in order to use that baseline for testing.
Currently I am dual booting KDE3 and TDE with mirror partitions of my base Slackware 13.1. Dual booting is, um, annoying. I have a couple of user accounts dedicated to testing. Installing TDE on my primary system would allow me to test under the exact same conditions without rebooting. I have a virtual machine with TDE installed, but I can't test everything there --- such as the video issues I discovered with the proprietary Nvidia drivers.
I need to run both with reasonable safety. Hence my desire to encourage some conversation about the topic.
Let me throw a question out to you coders:
Installing TDE alongside KDE should not be a problem with both using different a $PREFIX.
Will running both concurrently cause conflicts because the various app names and libraries use the same name?
That is, will be able to run one user account in KDE3 and another in TDE? Or will all accounts need to exit the desktop before running the other desktop? Or will be there no conflict because each environment is linked to different locations.
I didn't do it with KDE3/Trinity but with KDE4/Trinity I can run a regular KDE4 session, and a Trinity session as another user either in another X server or in Xnest; but I can't run both KDE3 and KDE4 as the same user on different X servers. There is no $PATH conflict since Trinity automatically adds $PREFIX/bin in top of the $PATH. But with KDE3/Trinity ld.so may get confused if Tim didn't make the necessary internal version number upgrades (and it seems libkdecore is still at 4.2.0 so it's a bad sign… with KDE 4.5 libkdecore is at version 5.5.0).
Having all accounts exit is a tad better than rebooting, but only a tad. :)
Opinions?
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I didn't do it with KDE3/Trinity but with KDE4/Trinity I can run a regular KDE4 session, and a Trinity session as another user either in another X server or in Xnest; but I can't run both KDE3 and KDE4 as the same user on different X servers. There is no $PATH conflict since Trinity automatically adds $PREFIX/bin in top of the $PATH. But with KDE3/Trinity ld.so may get confused if Tim didn't make the necessary internal version number upgrades (and it seems libkdecore is still at 4.2.0 so it's a bad sign… with KDE 4.5 libkdecore is at version 5.5.0).
Well, I can hear the peanut gallery in the background: the only way to know for sure is jump into the water and let everybody else know. I'm just trying to gather sufficient information to avoid anything nasty.
If either desktop freezes or crashes trying to run both concurrently, that is no big deal and probably nothing more than deleting cache files before restarting. Worst case is a library conflict that causes data corruption, but during those test I won't run critical apps like KMail.
As I said, although still inconvenient, fully exiting either desktop is better than rebooting. Not much, but still better.
Darrell
Le Tue, 6 Dec 2011 14:41:20 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
I didn't do it with KDE3/Trinity but with KDE4/Trinity I can run a regular KDE4 session, and a Trinity session as another user either in another X server or in Xnest; but I can't run both KDE3 and KDE4 as the same user on different X servers. There is no $PATH conflict since Trinity automatically adds $PREFIX/bin in top of the $PATH. But with KDE3/Trinity ld.so may get confused if Tim didn't make the necessary internal version number upgrades (and it seems libkdecore is still at 4.2.0 so it's a bad sign… with KDE 4.5 libkdecore is at version 5.5.0).
Well, I can hear the peanut gallery in the background: the only way to know for sure is jump into the water and let everybody else know. I'm just trying to gather sufficient information to avoid anything nasty.
If either desktop freezes or crashes trying to run both concurrently, that is no big deal and probably nothing more than deleting cache files before restarting. Worst case is a library conflict that causes data corruption, but during those test I won't run critical apps like KMail.
As I said, although still inconvenient, fully exiting either desktop is better than rebooting. Not much, but still better.
Excuse me, I apparently didn't read the part where you were saying that both worked separately. Since each user is separated by security policies there should be no problem running Trinity and KDE3 in parallel as different users.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Le 06/12/2011 20:33, Calvin Morrison a écrit :
Do we want to bother with making sure KDE3/Trinity can sit on the same PC?
I would like to be able to run my old amarok 1.4.10 in Trinity like in other DE. Most of all.
(That means it could be able to find its database in ~/.kde while trinity-amarok could be installed with its database in ~/.trinity)
KDE4 applications aren't a priority for me. I reported a bug because /usr/bin/konqueror (4.6.5) crashes in Trinity: it's a major bug but... it's a minor problem.
I would like to be able to run my old amarok 1.4.10 in Trinity like in other DE. Most of all.
(That means it could be able to find its database in ~/.kde while trinity-amarok could be installed with its database in ~/.trinity)
Why you can't you run TDE Amarok in other desktops? Just asking only to learn about any technical reasons.
Darrell
Le 06/12/2011 21:52, Darrell Anderson a écrit :
Why you can't you run TDE Amarok in other desktops? Just asking only to learn about any technical reasons.
Concerning Amarok, I only remember that I had a lot of problems to configure it and run it like I wanted to when I installed Trinity 3.5.12.
So I removed amarok-trinity at that moment and never tried it again.
I ran the lenny's version that I'm used to and didn't feel any need to change. But, sadly, it doesn't work anymore:
libamarok_void-engine_plugin.la not found libamarok_xine-engine.la not found
amarok-engine-xine 1.4.10 is still installed...
Concerning Amarok, I only remember that I had a lot of problems to configure it and run it like I wanted to when I installed Trinity 3.5.12.
So I removed amarok-trinity at that moment and never tried it again.
I ran the lenny's version that I'm used to and didn't feel any need to change. But, sadly, it doesn't work anymore:
libamarok_void-engine_plugin.la not found libamarok_xine-engine.la not found
amarok-engine-xine 1.4.10 is still installed...
Ah, I see. I'm a regular Amarok user too.
I don't know whether this will help, but in my dual boot setup with KDE3 and TDE, I ran some nominal tests with Amarok 3.5.13. Nothing unusual or unexpected happened. I did not perform exhaustive testing, but I never was an Amarok power user and would not know how to perform exhaustive testing with Amarok. But my playlists loaded and tunes sounded the same as in KDE3. Volume control worked, Pause button worked, I could hide or enable the menu, etc, and Amarok did not crash.
I migrated my KDE3 profile to TDE using my migration script. Therefore, all of my Amarok settings, config files, and databases were the same.
But you raise an interesting point about being able to concurrently run both KDE3 and TDE --- what happens when the TDE version breaks? As much as I am pressing here to get TDE as my primary desktop, the bugzilla contains some irritating bugs that are not yet resolved. Thus, cautious people will be tempted to use KDE3 in any transition. I know there are many patches in the bugzilla queue waiting to be merged, but after that happens I hope R14 sees a thorough scrubbing before release.
That is my personal goal: that by R14, TDE is my primary desktop, if not sooner. I'm so close right now. :)
Darrell
Le 06/12/2011 23:35, Darrell Anderson a écrit :
Ah, I see. I'm a regular Amarok user too.
I don't know whether this will help, but in my dual boot setup with KDE3 and TDE, I ran some nominal tests with Amarok 3.5.13. Nothing unusual or unexpected happened. I did not perform exhaustive testing, but I never was an Amarok power user and would not know how to perform exhaustive testing with Amarok. But my playlists loaded and tunes sounded the same as in KDE3. Volume control worked, Pause button worked, I could hide or enable the menu, etc, and Amarok did not crash.
I migrated my KDE3 profile to TDE using my migration script. Therefore, all of my Amarok settings, config files, and databases were the same.
But you raise an interesting point about being able to concurrently run both KDE3 and TDE --- what happens when the TDE version breaks? As much as I am pressing here to get TDE as my primary desktop, the bugzilla contains some irritating bugs that are not yet resolved. Thus, cautious people will be tempted to use KDE3 in any transition. I know there are many patches in the bugzilla queue waiting to be merged, but after that happens I hope R14 sees a thorough scrubbing before release.
That is my personal goal: that by R14, TDE is my primary desktop, if not sooner. I'm so close right now. :)
Thank you. I took the time to install amarok-trinity.
What I feared happened: I spent several hours resolving conflicts with debian-multimedia and wheezy packages. I had to downgrade and remove a lot of things. But now, it works.
I'll have to install it from sources because there's too much important packages I had to remove.
Thank you. I took the time to install amarok-trinity.
What I feared happened: I spent several hours resolving conflicts with debian-multimedia and wheezy packages. I had to downgrade and remove a lot of things. But now, it works.
I'll have to install it from sources because there's too much important packages I had to remove.
Sounds like the problem then is not Amarok TDE but the Debian package manager.
Glad you got things working. I had Amarok TDE running for more than an hour yesterday.
Darrell
Le 07/12/2011 18:41, Darrell Anderson a écrit :
Sounds like the problem then is not Amarok TDE but the Debian package manager.
Apt and Dpkg aren't to blame: they are made to upgrade packages. Downgrading always need some brain cells.
The main problem is that I use an unsupported system : debian testing with debian-multimedia packages. Trinity's Debian packages are for Debian stable ; they aren't fully and easily installable on Debian testing. And Trinity's Debian packages create conflicts with debian-multimedia/stable, another unofficial repository they can't deal with.
Since I removed all of KDE3 and KDE4 programs, I removed the origins of the problems that are discussed here ;-)
Glad you got things working. I had Amarok TDE running for more than an hour yesterday.
I'm really happy to run it again.
But... I did some simple tests: * /usr/bin/kedit (from KDE3 debian/lenny) is using ~/.trinity * /usr/games/amor (from KDE4 debian/squeeze) stores its files in the same folder. And when I start amor-trinity, it says there is a problem with nekokurorc... And I have to kill it, edit ~/.trinity/share/config/amorrc and restart it.
If I could have amarok and amarok-trinity at the same time, amarok would use ~/.trinity. And if I wanted to try amarok 2.3.1 (from KDE4), it will use the same folder, like other KDE4 programs and it will probably break the configuration files of amarok-trinity.
Maybe KDEHOME can be changed into TDEHOME for trinity's programs, so that /usr/bin/<KDE3-OR-KDE4-PROGRAM> uses its own folder in ~/kde or ~/kde4. Has it already been discussed?
Le 07/12/2011 18:41, Darrell Anderson a écrit :
Sounds like the problem then is not Amarok TDE but the Debian package manager.
Apt and Dpkg aren't to blame: they are made to upgrade packages. Downgrading always need some brain cells.
The main problem is that I use an unsupported system : debian testing with debian-multimedia packages. Trinity's Debian packages are for Debian stable ; they aren't fully and easily installable on Debian testing. And Trinity's Debian packages create conflicts with debian-multimedia/stable, another unofficial repository they can't deal with.
Since I removed all of KDE3 and KDE4 programs, I removed the origins of the problems that are discussed here ;-)
Glad you got things working. I had Amarok TDE running for more than an hour yesterday.
I'm really happy to run it again.
But... I did some simple tests:
- /usr/bin/kedit (from KDE3 debian/lenny) is using ~/.trinity
- /usr/games/amor (from KDE4 debian/squeeze) stores its files in the same folder. And when I start amor-trinity, it says there is a problem with nekokurorc... And I have to kill it, edit ~/.trinity/share/config/amorrc and restart it.
If I could have amarok and amarok-trinity at the same time, amarok would use ~/.trinity. And if I wanted to try amarok 2.3.1 (from KDE4), it will use the same folder, like other KDE4 programs and it will probably break the configuration files of amarok-trinity.
Maybe KDEHOME can be changed into TDEHOME for trinity's programs, so that /usr/bin/<KDE3-OR-KDE4-PROGRAM> uses its own folder in ~/kde or ~/kde4. Has it already been discussed?
--
There is a rename project currently ongoing to deal with things like that. See http://trinity.etherpad.trinitydesktop.org/17 for a list.
It looks like KDEHOME has not yet been dealt with, but will be before the R14.0 release.
If anyone else notices items that are not on the previously-linked list please add them in the TODO section.
Tim
Apt and Dpkg aren't to blame: they are made to upgrade packages. Downgrading always need some brain cells.
The main problem is that I use an unsupported system : debian testing with debian-multimedia packages. Trinity's Debian packages are for Debian stable ; they aren't fully and easily installable on Debian testing. And Trinity's Debian packages create conflicts with debian-multimedia/stable, another unofficial repository they can't deal with.
Since I removed all of KDE3 and KDE4 programs, I removed the origins of the problems that are discussed here ;-)
Glad you got things working. I had Amarok TDE running
for more than an hour yesterday.
I'm really happy to run it again.
But... I did some simple tests:
- /usr/bin/kedit (from KDE3 debian/lenny) is using
~/.trinity
- /usr/games/amor (from KDE4 debian/squeeze) stores its
files in the same folder. And when I start amor-trinity, it says there is a problem with nekokurorc... And I have to kill it, edit ~/.trinity/share/config/amorrc and restart it.
If I could have amarok and amarok-trinity at the same time, amarok would use ~/.trinity. And if I wanted to try amarok 2.3.1 (from KDE4), it will use the same folder, like other KDE4 programs and it will probably break the configuration files of amarok-trinity.
Maybe KDEHOME can be changed into TDEHOME for trinity's programs, so that /usr/bin/<KDE3-OR-KDE4-PROGRAM> uses its own folder in ~/kde or ~/kde4. Has it already been discussed?
I believe the environment variables are being changed during Tim's Great Big Git Migration.
Last year when I rebuilt KDE3 for Slackware 13.1, I patched KDE3 to change the environment variables to KDE3HOME, KDE3DIR, etc. I patched the packages for a KDE3HOME of $HOME/.kde3 and not .kde.
All of that avoids conflicts with KDE4.
With those changes I probably am in a small club of people who can install KDE3 and TDE concurrently and not worry about environment variables clashing. I still need to write some modified xinit or bashrc scripts.
Darrell
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Laurent Dard -
Timothy Pearson