| Summary: | Address further potential conflicts with KDE4 | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | other (any) | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bugwatch, darrella, julius.schwartzenberg |
| Priority: | P1 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | 1035, 1036, 1037, 1038, 1039 | ||
| Bug Blocks: | |||
I'm starting to think that rather than append menu items with [KDE3] or [KDE4] that each desktop should receive its own top level menu. Right now the menu is a cluttered mess when either desktop is installed along with Trinity. I am having good success with items 2 and 3 in the original problem description. With further testing I discovered numerous problems with item 1. Odd things occur in my builds when I change the directory name $PREFIX/applications/kde -> $PREFIX/applications/trinity. Something in the source code or build process is hard-coded to $PREFIX/applications/kde. I have not determined where that happens. I can demonstrate the hard-coding by creating a sym link from $PREFIX/applications/trinity to $PREFIX/applications/kde. After restarting the session most of the odd problems disappear, which indicates hard-coding. With the changes in items 2 and 3, I have had nominal success tinkering with separate KDE4 menus so as to not clutter the main TDE menu. This is successful because the references in all *.desktop files get changed for TDE apps, which avoids collisions with KDE3/4 desktop files. With some work we should be able to populate KDE3/4 apps in their own menus using only XDG menu files. To support that I am testing patches with changing the $PREFIX/share/desktop-directories files to tde-* rather than kde-*. This further distinguishes Trinity from KDE4. Thus far the patches seem to be working successfully. Using an XDG menu approach, there would be no need to append KDE4 menu items with [KDE4]. I need help solving why I can't change the name of $PREFIX/applications/kde -> $PREFIX/applications/trinity. I have not merged any patches because testing needs to be thorough. I ran a test of changing $PREFIX/applications/kde -> $PREFIX/applications/trinity without modifying any XDG references anywhere. Just the one change. Again Trinity breaks because of some obtuse hard-coding to $PREFIX/applications/kde. I have looked hard for this hard-coding but somebody else will have to help.
Additionally, when the patches for this bug report are merged, any user who has an existing Trinity profile directory needs to have the entire profile searched to replace X-KDE -> X-TDE. Like this:
find .trinity -type f -exec sed -i 's|X-KDE|X-TDE|g' {} \;
Without that one-time change all mimetypes will be incorrect and odd things happen, such as the Konqueror side bar refusing to display.
tdelibs menu prefixes updated in GIT hash b72ffa4cc88aefb707471d6467df7cbe066502a2. tdebase menu prefixes updated in GIT hash 56f943b3df79554e91b4f006c55650bf7661035f. tdemultimedia menu prefixes updated in GIT hash a70dc7101e1f1be71968a383cd30fb02689886b1. tdevelop menu prefixes updated in GIT hash 48a05a0f887545e61b799e48a206ede341cb925a. I'm stalled with this bug report. :(
I have patches for all modules that need to be updated from "X-KDE" -> "X-TDE" and "KDE;" -> "TDE;", mostly in *.desktop files but also in some code strings. I have been using these patches in my GIT builds with no ill effects, although I have not yet performed exhaustive testing to ensure these changes avoid conflicts with KDE3/KDE4.
I can't push those patches to GIT because:
1. I do not know how to automate updating the user's profile directory with the same changes. I know kconf-update is used but I don't know anything more than that. Without automatically updating the user's profile little things break because of the mismatched XDG strings. If I push the patches then everybody using those patches will find their profiles broken. For now that only affects GIT testers, but eventually would affect all users with the official R14 tarballs.
Effectively, kconf-update needs to perform the equivalent of the following:
find $TDEHOME -type f -exec sed -i 's|X-KDE-|X-TDE-|g' {} \;
find $TDEHOME -type f -exec sed -i 's|KDE\;|TDE\;|g' {} \;
kconf-update needs to know that these changes have been performed so as not to repeat the task with each subsequent session.
2. I don't know how to change $PREFIX/applications/kde -> $PREFIX/applications/tde. Little things break every time I try to do that. Something in the system is hard-coded to look only in $PREFIX/applications/kde. I have been unsuccessful discovering where or how. Changing that path is desirable for when packagers install Trinity to the same $PREFIX as KDE3 or KDE4, or to create a more manageable menu system when Trinity is installed concurrently with KDE3 or KDE4.
As mentioned in Comment 2, this hard-coding can be shown by creating a sym link from $PREFIX/applications/tde to $PREFIX/applications/kde. After restarting the session the oddball problems disappear.
3. Although fixing the way KDE3/KDE4 apps are added to the menu system is desirable, I will open a new bug report for those corrections/enhancements. That move allows this bug report to be closed by resolving the two mentioned issues and pushing the existing available patches.
Bug report 977 created to address the conflicts with KDE3 and KDE4 in the menu system. Moving those items to a new bug report means this bug report could be closed after addressing the issues in the previous comment. > 1. I do not know how to automate updating the user's profile directory with the
> same changes. I know kconf-update is used but I don't know anything more than
> that. Without automatically updating the user's profile little things break
> because of the mismatched XDG strings. If I push the patches then everybody
> using those patches will find their profiles broken. For now that only affects
> GIT testers, but eventually would affect all users with the official R14
> tarballs.
>
> Effectively, kconf-update needs to perform the equivalent of the following:
>
> find $TDEHOME -type f -exec sed -i 's|X-KDE-|X-TDE-|g' {} \;
> find $TDEHOME -type f -exec sed -i 's|KDE\;|TDE\;|g' {} \;
>
> kconf-update needs to know that these changes have been performed so as not to
> repeat the task with each subsequent session.
One way to handle this, though probably not ideal, is to create a script that goes into each $HOME/.trinity directory and runs those sed commands. A link to this script could go into the release notes for R14.0, and post-upgrade hooks to run that script could be added to R14.0 packages on distributions that support them.
Updating the user's profile must be automatic and seamless. Expecting manual updating will create havoc and contempt. How does kconf-update play a role in updating user profiles? I still can't find the hard-coding to $PREFIX/applications/kde. Every attempt I have made to change that directory name to $PREFIX/applications/tde has failed. Only the core packages need to be built (through tdebase) to test this problem. When these two problems are solved I can start pushing the full change set to GIT. (In reply to comment #8) > Updating the user's profile must be automatic and seamless. Expecting manual > updating will create havoc and contempt. Agreed. > How does kconf-update play a role in updating user profiles? Not sure--TDE is a large and complex system, and I am still not familiar with some parts of it. > I still can't find the hard-coding to $PREFIX/applications/kde. Every attempt I > have made to change that directory name to $PREFIX/applications/tde has failed. > Only the core packages need to be built (through tdebase) to test this problem. > My guess is that there is a #define set during the build process. I would check to see if there is a #define set in config.h after the build starts--if so, then the build system will need to be updated as well. I'm comfortable saying we can fine-tune the original sed searches to just desktop files:
find $TDEHOME -name "*.desktop" -exec sed -i 's|X-KDE-|X-TDE-|g' {} \;
find $TDEHOME -name "*.desktop" -exec sed -i 's|KDE\;|TDE\;|g' {} \;
Of course, this would be needed only for existing profiles, not new.
I didn't find anything obvious in any config.h files.
As far as I can tell, kconf_update is limited to config files in $TDEHOME/share/config. Adding a simple shell script in tdelibs or tdebase is straightforward, but now we need a way to launch that script and launch only once. Doing so through starttde would be one way but where to store the information that the "cleanup" script has been run? We can create a unique profile rc or store the information in an existing rc file like kdeglobals. Possibly create a group name of [R14 Profile Update] and a key/value of Updated=true. Much progress since the previous comments were posted!
We now know how to fix the ${SHARE_INSTALL_PREFIX}/applications/kde -> ${SHARE_INSTALL_PREFIX}/applications/tde name change. Apparently this is an app-specific problem and needs app-specific patching. The fix requires changing certain source code instances of kde-*.desktop to tde-*.desktop.
I patched starttde (not uploaded anywhere yet) to fix profile *.desktop files with the same related XDG changes (refer to Comment 10). The profile fix is applied only once. The result is saved in the user's kdeglobals config file. The updates are run only with an existing $TDEHOME profile and are not executed with a new profile. Works well.
At this point I think we're about as close as we can get to pushing this entire large patch set. We could ask for volunteers to test the entire patch set, but because every individual module needs to be patched during the build process, that request is clunky and very few people, if any, would volunteer for such massive labor. I will test for a while more in the hopes of finding any additional oddball apps that need unique patching. Yet the reality is more eyes beyond mine are better suited to find those anomalies. That is, eventually we should just push the entire patch set, announce the patches to the mail list, and let the usability testing begin. The sooner the better, to provide ample time for such testing before implementing any soft freezes in the source code.
Do I expect further breakage such as that seen in konqueror? The cowardly answer is yes, but as I have been fiddling with this for a while, I expect very little breakage.
Just as important, should such oddball breakage be found, we now know where to start looking: in the source code to change an instance of kde-*.desktop to tde-*.desktop.
For bug tracking purposes, only the following packages have kde-*.desktop references in the source code: applications/tde-systemsettings applications/kerry applications/kiosktool applications/knutclient tde-i18n tdebase tdebindings tdelibs tdevelop That is, after pushing the patches to GIT, these packages are the only ones where we might expect breakage. Go ahead and push when ready. I suspect that outside of tdebase there should'nt be any ill effects, as tdebase is the only module in your list that still deals heavily with XDG magic. (In reply to comment #14) > Go ahead and push when ready. I suspect that outside of tdebase there > should'nt be any ill effects, as tdebase is the only module in your list that > still deals heavily with XDG magic. That should read tdelibs/tdebase, not just tdebase. Tim On closer inspection, we can remove tde-i18n, tdebindings, and tdevelop from the list. tde-i18n contains nothing but *.po and *.docbook string references and no actual source code. tdebindings has only two comments containing kde-*.desktop references. tdevelop uses the references only in templates. kiosktool and knutclient probably are out of consideration too. That leaves the potential trouble list to this: applications/tde-systemsettings applications/kerry tdebase tdelibs I plan to use a fully patched Trinity desktop for several days. I'll push the patch set thereafter and forewarn the developer's list. Massive patch set pushed to GIT Friday, June 8, 2012. I'll keep this bug report open for a couple of weeks to allow for feedback and bug reports from testers. Looks like testers are reporting some breakage...I am adding those bugs as dependencies to this report. It appears the current migration commands are not working in all cases as intended. I guess not all edge cases are covered yet.
In my case, I found that this command:
find ${HOME}/.trinity -name *.desktop
Does *not* give any output. In my case it was because .trinity is a symlink to .kde3. This command does list all the .desktop files in my .trinity directory:
find -H ${HOME}/.trinity -name *.desktop
Checking the .desktop files in there, they are indeed not updated and still have KDE everywhere. However at the same time this command:
kreadconfig --file kdeglobals --group "R14 XDG Updates" --key Updated
Returns: true
I guess adding -H will solve the issue for my case. Other edge cases that I can come up with, which should be tested (and maybe dealt with) in some way:
- /home is a symbolic link (maybe this -H will also address this if it doesn't work already)
- there are spaces in $tdehome (there should be quoting in the appropriate places to solve this)
- some directories or files within them are read-only, either the user does or does not have permission to change the permissions (it's not the owner) or it does (probably can only be addressed by displaying a proper error message)
- a user is still running another KDE3/Trinity session on this same profile directory which still uses the old prefix; When /home is an NFS mount it's not uncommon to be logged onto multiple systems with the same profile (I often had this in uni) (a check for the profile being in use and canceling the log-in with a "Migration cannot be performed at this time." error should deal with it)
Some other general suggestions about this migration. I would propose moving the migration lines to its own script and calling that script from starttde. This script could later on also be called by a user on the command line to perform diagnostics regarding the migration. Two options I imagine are:
1. One to check migration status in the configuration
2. One to verify all .desktop files are migrated
This would ease debugging the migration status in case users have problems due to a partial migration.
Your case is one I never thought about or anticipated. Another example of how all humans are creatures of limited knowledge. :-) I use both KDE 3.5.10 and Trinity GIT. I keep the former running because I have other systems running KDE3 and also to use for comparison testing against GIT. I'm using Trinity GIT as my primary desktop. Because I have both KDE3 and Trinity installed concurrently, I use some sym links to share some profile subdirectories between $HOME/.trinity and $HOME/.kde3, such as akregator, kalarm, kmail. I never sym linked the entire profile directory because I knew about the differences. After some consideration, we can't support a commonly shared profile directory between the two desktops. The latest (necessary) XDG updates prevent that. The XDG updates change the nature of how the configuration files are used with respect to each desktop. I can't think of any way to make a shared profile directory compatible with each desktop. :-( Yet there is remedy. :-) If you do not concurrently use KDE3 and Trinity, then exit/logout your Trinity session and rename the directory. If you use both desktops then there is remedy for that too. Be sure to not be logged into Trinity. Break your sym link between $HOME/.trinity and $HOME/.kde3 and create a new $HOME/.trinity. Not a clean, fresh profile where you have to reconfigure every thing --- no, no, no. :-) Copy $HOME/.kde3 to $HOME/.trinity. Duplicate the directory. Don't panic--- use a script to do that. I have a KDE3 -> Trinity profile migration script. The script never was pushed upstream but is available in bug report 709. I just now uploaded the latest version. If you're curious, I tested the migratekde3 script about a week ago. The migratekde3 script does not perform the XDG updates performed in starttde. Therefore creating and updating $HOME/.trinity will look like this: * Log out of Trinity. Note: I never tried this, but I don't see why you can't be logged into a KDE3 session to run the migration script. * From a console or terminal window in a different desktop, break the sym link between $HOME/.kde3 and $HOME/.trinity. * From the same console or terminal window, run the migratekde3 script, which will duplicate the $HOME/.kde3 profile directory to $HOME/.trinity. The script makes several nominal changes to support the Trinity environment. * In the newly created $HOME/.trinity, open kdeglobals with a console text editor and [R14 XDG Updates] Updated=false. Or use kwriteconfig. You are the only person needing to do this because of your unique situtation. :-) * Login to Trinity. The starttde script will update the newly duplicated profile with all the XDG updates. Let me know how that goes. If disk space is a concern, then consider sym linking some profile subdirectories, as I mentioned I do. Here are the profile subdirectories and files I currently sym link between the two profiles: $HOME/.trinity/share/apps/konqueror/bookmarks.xml $HOME/.trinity/share/apps/kaffeine $HOME/.trinity/share/apps/digikam $HOME/.trinity/share/apps/kmail $HOME/.trinity/share/apps/konsole/bookmarks.xml $HOME/.trinity/share/apps/akregator $HOME/.trinity/share/apps/kate/fsbookmarks.xml $HOME/.trinity/share/apps/kalarm $HOME/.trinity/share/apps/amarok $HOME/.trinity/share/apps/kfile/bookmarks.xml By far the biggest subdirectory is $HOME/.trinity/share/apps/kmail. That sym link shares the mail data but not the configuration files. That saves me a lot of disk space. I'm not noticing any problems with those sym links. Regarding other points raised by Julius: The snippets in starttde do not provide error checking --- they only execute. When no text is found that should be updated, the snippets do not fail. Thus the kdeglobals config file gets updated regardless of the results. I don't yet know how we might remedy that. At the moment I am not going to rush to add the -H option. Because with the XDG updates the Trinity and KDE3 profiles now partially incompatible, both desktops need their own separate profile directories. Sym linking worked up until the XDG updates. In a sense that is good for you because your KDE3 profile never updated. Thus if you concurrently use both KDE3 and Trinity, your KDE3 profile remains intact for usage in KDE3. Which is another reason I'm not favoring the -H option. As much as we would like to see Trinity used and KDE3 not :-), we can't stop people from using both. Should others also sym link the two profile directories, adding the -H option would break the profile for KDE3 usage. With respect to moving the XDG snippets from starttde to a separate script, originally I considered that option. I remain open to the option. I did not do so mainly because the additional commands are few and the updating event is a one-time occurrence. A separate script would allow for more tinkering, robustness, diagnostics, etc. I'm open to suggestions. I think your case of sym linking the two profile directories is unique. At least, I hope! :-) For the moment that corner case does not urge me to create a separate script or tinker with the existing starttde snippets. The XDG updates render the two profiles incompatible and we need to acknowledge and accept that change. I will update starttde to address spaces in $tdehome (and $TDEHOME). Would you please provide me examples of files in $TDEHOME that are read-only or owned by other users? I will look into updating the migratekde3 script to cover the case of users sym linking $HOME/.trinity to $HOME/.kde3. The script needs to know about that and break the sym link before duplicating. Thanks so much for your patience and testing. :-) Actually, I do not use KDE3 anymore. I just had a symlink because I wasn't sure which one Trinity would pick as some point, .kde3 or .trinity. I'll just migrate my profile to .trinity. My situation is not unique regarding the fact that there can always be one or more symlinks in the $tdehome path. The migration should never silently fail, but somehow cope with this. People may want to have their KDE/Trinity settings in a local folder for instance, while their homedir is on a network mount. They would create a symlink then as well. On many systems I managed, /home was a symlink to a home directory on a mountpoint that also contained /var. This should also be tested. Read-only files is also an edge case which should be covered even though it may not be clear why the files in particular are read only. Read-only configuration files are very common in locked down KDE/Trinity set-ups btw. There is even code so that configuration options that cannot be changed are greyed out when looking at them through kcontrol. I don't know about *.desktop files, but I wouldn't be surprised to come across them as read-only as well. While all these edge cases like spaces in $tdehome seem crazy, it's always best to document them and try to cope with them and preferably also test with them. The assumption that people will use a single profile with 2 DEs is one that really cannot be made. Trinity should be able to assume full control over anything inside .trinity (even if a dumb user has it symlinked to .kde3 and still uses KDE3 as well). If there would be a script that migrates .kde or .kde3 to .trinity, it should just leave the original directory intact for the case the user still uses KDE3. I have added to starttde an error check to not perform the R14 XDG updates when $tdehome is a sym link. The error check will add respective messages in the xsession log. I haven't yet tested, which I will do before pushing the patch to GIT. Although you are correct that Trinity should have full reign within its own profile directory (limited to administrative locking), the error check will bypass problems for those sym linking profile directories. Not performing the updates will cause breakage in the Trinity session --- as you have noticed :-), but that seems to be a conservative approach --- for the moment. I'm adding extra verbage in the xsession message why the R14 XDG updates are not performed and that breakage can be expected without the R14 updates. I'm adding a "TODO" note in starttde to remind me, and others, that we need to address files that are locked administratively. I added quotation marks to resolve the problem with spaces in the directory name. I still need to test that too. :-) As I mentioned previously, I will do something similar with the migratekde3 script. Yes, we need to address corner cases. You reminded me that in certain environments parts of the Trinity profile will be locked. I even use these controls in my home theater PC, which runs KDE3. :-) I never considered file locks with respect to the R14 XDG updates. I'll have to tinker to simulate file locking. Minimally, I'll add some output in the xsession log. I'm unsure that this will be a huge problem. The various *.desktop files that need to be updated will be in $TDEHOME/share/apps and not in $TDEHOME/share/config, where I believe the locking occurs (my memory could be faulty too). I don't know whether khotkeysrc, profilerc, and Autostart files can be locked. I'll have to find and review that documentation. I have a full network running here and can simulate an NFS shared $HOME. As my computer is not in a controlled environment, I appreciate help with examples that I can create here to simulate and test. :-) I don't think many users will check their xsession logs quickly when a log-in fails. I'd rather get a dialog when the migration fails (maybe with kdialog?) which says something along the lines: "Unable to update your Trinity settings to cope with the new Trinity version. Please run <migration script name> <options> <path to tdehome> on a terminal to diagnose the problem." After which the session is killed. I wouldn't expect many regular users to see this, especially if the script can deal with symlinks appropriately. The few users that would get this message would likely know (or have an admin that knows) how to run the script from a terminal or fail-safe session, where it could output the problems in detail. In case it concerns read-only files, running the migration script as root, would just allow it to fix the problems. Another advantage of a separate script is that a system administrator can use it to manually update all its users profiles beforehand. The idea of an xsession log entry is for administrators. With that output I might have been able to ask you whether that message exists, which would have provided us both help about learning why the failures occurred. Regarding kdialog, that sounds like a good idea. Except at that point in the starttde script, Trinity has not yet initialized to be able to use kdialog. :-( I recall we discussed something similar in the developer's list a long time ago about that problem. Our only choice at that point is to use the ugly X dialogs. Ugly but doable. Let me look into that along with these other changes. We won't need to kill the session. One, that seriously irritates users. :-) Two, in my testing, Trinity runs without the R14 XDG updates although certain portions break or act weird. Nonetheless the desktop remains functional and mostly usable. Examples of breakage: * Apps or applets break that use left-side icon lists, such as the Panel and Konqueror configurations. * User-defined keyboard shortcuts fail (khotkeysrc). System defined shortcuts remain functional. * User-defined app preferences fail (profilerc). For example, on my system, which has Xfce installed, thunar opened when I tried to open directories in konqueror. Irritating. :-) * The konqueror navigation/sidebar panel refuses to open. * Anything that uses a *.desktop file acts weird: user-defined konqueror service menus, kicker customization, konqueror sidebar, Recent Documents. The idea of moving to a separate script such that administrators, who have full write privileges, is a good reason. Not sure where to move the script. Probably $PREFIX/bin is the safest place. I need a name for the script ---- r14-xdg-update.sh or something similar. If the session is not killed. I suppose it would be good to describe the possible broken behavior in the dialog box that will show up. *** Bug 1037 has been marked as a duplicate of this bug. *** Latest starttde update and new r14-xdg-update script pushed to GIT in hashes 6ebf92cb and 5464fc6f. I'm closing this report as resolved. We have had only one corner case problem. Of course, anybody can reopen should new problems arise. :-) |
1. Through TDESetupPatches.cmake, all desktop files currently are installed to ${SHARE_INSTALL_PREFIX}/applications/kde. That should be changed to ${SHARE_INSTALL_PREFIX}/applications/tde or ${SHARE_INSTALL_PREFIX}/applications/trinity. The latter is consistent with other directory name changes and more readily identifiable by users. I have tested the latter with no noticeable problems. (Thus far I have been using a one-liner on-the-fly proof-of-concept patch and don't have individual patches for all 117 modules.) 2. All XDG related information should be changed from "KDE" to "TDE." For example, Categories:KDE; -> Categories:TDE;, X-KDE-AutoEmbed -> X-TDE-AutoEmbed, etc. 3. All TDE menus should be updated with the same XDG changes. I have tested these changes with the core packages and thus far noticed only one minor problem. After applying these changes, the user's $TDEHOME profile must be searched to replace all occurrences of X-KDE with X-TDE. A simple sed search fixes the problem. Possibly such a one-liner could be added to the tdelibs or tdebase source code or starttde so users never notice anything. These cumulative changes will further help avoid potential conflicts with KDE4. All of these changes would be consistent with the patches for bug report 840. The first patch can be performed without needing to apply the second set of patches. With these changes there remains one noticeable conflict: with KDE3. 4. Currently there exists no method to distinguish TDE and KDE3 apps in the TDE menu when both desktops are installed concurrently. Although Trinity developers do not officially support KDE3, users can still install both. There exists a method to distinguish KDE4 apps by appending "[KDE4]" to the menu description (kservice.cpp). A similar method should be added for KDE3 apps. By changing ${SHARE_INSTALL_PREFIX}/applications/kde -> ${SHARE_INSTALL_PREFIX}/applications/trinity, there then would be available a method to detect and distinguish TDE and KDE apps because KDE3 apps would be installed to share/applications/kde or share/applications/kde3. Something like this: bool kde3application = config->fileName().contains("share/applications/kde3/") || \ config->fileName().contains("share/applications/kde/"); The remaining code that was added in order to append [KDE4] in the TDE menu needs more robust testing to distinguish between KDE4 and KDE3, but this seems doable with the previous changes.