Looks like the problem is not the r14-xdg-update script but the starttde script. At line 293 of starttde:

if [ "$R14_UPDATED" != "true" ] || [ "$R14_VERSION" -lt "$R14_SCRIPT" ]; then

A person already running git packages has long ago updated any existing KDE3 or Trinity 3.5.x profile to the latest R14 standards. Although we might still find a few missing items that should be added to the r14-xdg-update script, likely subsequent updates are no longer needed or desired by present git users.

The same will apply to all users who update to the official R14.0.0. Any change to the r14-xdg-update script will do exactly as I described with my intentional KDE4 desktop files.

Perhaps the test at line 293 in starttde should be changed to a logical AND:

if [ "$R14_UPDATED" != "true" ] && [ "$R14_VERSION" -lt "$R14_SCRIPT" ]; then

With this change any existing git user will always see $R14_UPDATED == true, which will stop that snippet of code from executing, even when [ $R14_VERSION -lt $R14_SCRIPT ]. Likewise, future R14.0.0 users also will no longer see any execution of the r14-xdg-update script.

Created attachment 1815 [details]
Updated r14-xdg-update script for approval

Note 1: Is there any idea how to tell which files is suitable for replacement X-KDE-=> X-TDE and KDE; => TDE; and which are not?

Note 2: I'm not sure if in the future will not follow any other renaming, and therefore prefer to assume that they will. I therefore propose a different modification of the script. Thanks to the mark with the script version it is possible on next run execute only the newly added rules.

Note 3: I modified the method of logging messages, so that might not always be Message_Prefix => echo. The newly prepared function Log also allows multi-line messages, where Message_Prefix is added before each line of the message.

See the attached updated script.

What is significant about the date 201309150? Perhaps that date should be set at the beginning of the script as a variable with comments explaining the meaning or origin of the date?

>Is there any idea how to tell which files is suitable for replacement
>X-KDE-=> X-TDE and KDE; => TDE; and which are not?
That was the first thing I investigated after I understood what was happening. There is no dependable way using the contents of the desktop files. Yet I have considered a possible detection method.

When a user adds custom items to the launcher menu, whether in Trinity or KDE4, an associated desktop file is created. Also a custom menu is created in $HOME/.config/menus.

The related desktop files will be itemized in the user's custom menu.

At the moment, Trinity and KDE4 use the same name for the custom menu name: applications-kmenuedit.menu.

This is not good. I will open a bug report to change the name to applications-tdemenuedit.menu. I have been aware of this conflict for a long time and should have opened a bug report long ago.

In my particular use case, because I have custom menus for both Trinity and KDE4, I use a pre-login script to help me toggle between the two desktops. At the moment I name the two menus applications-kmenuedit.menu.trinity and applications-kmenuedit.menu.kde. As necessary my pre-login script copies and overwrites one or the other menu to applications-kmenuedit.menu.

Most users will have not have such an elaborate configuration. At most they will have only one custom menu: applications-kmenuedit.menu. We use that menu to detect whether desktop files should be updated in .local/applications.

When a user updates from 3.5.x to R14.0.0, there will be at most only one applications-kmenuedit.menu, if any custom menu exists. After we resolve the problem that both KDE4 and Trinity both use the custom menu name of applications-kmenuedit.menu, in r14.xdg-update we then rename applications-kmenuedit.menu to applications-tdemenuedit.menu. A one-time event.

Should any Trinity user thereafter also use KDE4 and customize the KDE4 menu, the KDE4 custom menu will be named applications-kmenuedit.menu. No conflicts with menu names but there might be conflicts with desktop files belonging to the KDE4 custom menu rather than the Trinity custom menu.

Because the custom menus now have different file names, we have r14-xdg-update grep any existing applications-tdemenuedit.menu for the existence of any desktop file found in .local/applications. When the desktop file is found in the custom menu we presume the desktop file is part of the Trinity custom menu. When the desktop file is not found in applications-tdemenuedit.menu we presume a KDE4 menu item.

(Odpověď na komentář #3)
> What is significant about the date 201309150? Perhaps that date should be set
> at the beginning of the script as a variable with comments explaining the
> meaning or origin of the date?
> 

The tag 201309150 is only interesting that it was the first to be used => we are unable to distinguish updates performed before this tag. Therefore, most of the conditions is with this tag.

I did not add to the file the list of used tags with comments because it would duplicate the changelog, which is available in git.

I am not sure whether to put on top of the file comment like this: "When you edit the file, be sure to update tag indicating the version. When you add more rules, use for them condition relating to the new tag." I see it as a comment to the programmer, not for the user.

I believe that the proposed script modification in attachment 1815 [details]
can be pushed regardless of bug 1805. What do you think?

>I am not sure whether to put on top of the file comment like this:
I did not explain my self well. I meant add 201309150 as a variable at the beginning/top of the script and add a comment only about that variable. Like this:

===============================
# The variable $SCRIPT_GO_LIVE_DATE is when we first used
# this script in a production manner. Detecting changes
# performed before this date is not possible, although only
# affecting git users. The date is a script "go live"
# reference point, something like "epoch zero." :)
SCRIPT_GO_LIVE_DATE="201309150"
===============================

>I believe that the proposed script modification in attachment 1815 [details]
>can be pushed regardless of bug 1805. What do you think?
Yes, although I'd rather see 201309150 as a variable, as just described. Not critical, just nice to my eyes and thinking. :)

I am creating patches for bug 1805. I can't proceed with patching r14-xdg-update until the changes proposed here are pushed to git.

Do we still need to modify starttde (refer to comment 1)?

(Odpověď na komentář #6)
> >I am not sure whether to put on top of the file comment like this:
> I did not explain my self well. I meant add 201309150 as a variable at the
> beginning/top of the script and add a comment only about that variable. Like
> this:
> 
> ===============================
> # The variable $SCRIPT_GO_LIVE_DATE is when we first used
> # this script in a production manner. Detecting changes
> # performed before this date is not possible, although only
> # affecting git users. The date is a script "go live"
> # reference point, something like "epoch zero." :)
> SCRIPT_GO_LIVE_DATE="201309150"
> ===============================
> 
> >I believe that the proposed script modification in attachment 1815 [details]
> >can be pushed regardless of bug 1805. What do you think?
> Yes, although I'd rather see 201309150 as a variable, as just described. Not
> critical, just nice to my eyes and thinking. :)
> 
> I am creating patches for bug 1805. I can't proceed with patching
> r14-xdg-update until the changes proposed here are pushed to git.

Using variables for a single date/tag does not seem a good idea. As you can see in the script are already used tags: 201309150, 201310050, 201310190 and 201312160. Create a variable for all used tags is nonsense. And use in some conditions variable, while in the other will be a particular tag, in such a case could be confusing.

In addition, variable gives the impression that it's something that can be changed. But that's for this variable a fundamental mistake.

I considered whether to put into the script your explanatory comment - not for the variable, but for this one specific tag. But it could then give the question, why are not comments also for other tags. And now we are back - it would be a duplication of GIT changelog.

(Odpověď na komentář #7)
> Do we still need to modify starttde (refer to comment 1)?

No, the change in starttde is undesirable. We should expect updates that may require repeated run of the r14-xdg-update. And script r14-xdg-update will be ready to handle only new rules.

>No, the change in starttde is undesirable.
Then we'll see how the new r14-xdg-update script works.

(Odpověď na komentář #10)
> >No, the change in starttde is undesirable.
> Then we'll see how the new r14-xdg-update script works.

So I am going to push the proposed modification.

Comment on attachment 1815 [details]
Updated r14-xdg-update script for approval

Pushed to GIT in hash 30038436.

After performing several tests in bug 1805 along with a revamped r14-xdg-update script, we can close this bug report as soon as all patches in bug 1805 are pushed to git.