Created attachment 1816 [details]
tdelibs patch

Created attachment 1817 [details]
tdebase patch

This tdebase patch does not include necessary changes to the r14-xdg-update script. Those changes will follow in an additional patch.

Created attachment 1818 [details]
kiosktool patch

Created attachment 1819 [details]
tde-i18n patch

Looks good; push when ready.

Tim

Created attachment 1820 [details]
Proposed r14-xdg-update script (full file)

Slavek,

Please review the proposed r14-xdg-update script changes. I attached as a full file because I thought that would be easier to read and study.

Basically I moved all custom menu related tests and updates to the same place in the script to keep a;; of those items together, especially now that the script will attempt to rename any existing kmenuedit.menu file. I added some nominal tests to help distinguish whether the menu is KDE4 or TDE.

I need help with testing whether a $HOME/.local *.desktop file is TDE or KDE4. At line 685 you'll see my comment asking for review and improvement. (Remove the comment. :) )

I added liberal commentation to explain what we are trying to accomplish.

I fixed a few bashisms I noticed had crept into the script.

Created attachment 1827 [details]
Proposed r14-xdg-update script (full file)

Updated with minor typographical fixes.

Updated r14-xdg-update attached. Minor typographical fixes.

Test 1
======

I started an existing pre R14 Trinity environment that had no custom KDE4 or TDE menu. In Trinity I created one TDE menu item and the new menu was saved correctly as applications-tdemenuedit.menu.

Test 2
======

I used a KDE 3.5.10 profile directory and the migratekde3 script to create a Trinity 3.5.13 profile directory. I copied my existing pre R14 Trinity custom menu, applications-kdemenuedit.menu, and did not manually rename the menu. I edited $HOME/.local/share/applications/*.desktop as necessary to create a 3.5.13 environment (reverting TDE->KDE). I then started Trinity, simulating a 3.5.13 user who had not used KDE4. No menu problems at all. Nothing in Lost+Found, and applications-kdemenuedit.menu was renamed to applications-tdemenuedit.menu.

In the next two tests things got messy.

Test 3
======

I simulated a KDE4 user using Trinity for the first time. I renamed my existing pre R14 Trinity profile to force creating a new Trinity profile. This user had a KDE4 custom menu, of which some *.desktop items had OnlyShowIn=KDE. Of those desktop items that had OnlyShowIn=KDE, none were included in the Trinity menu Lost+Found submenu. Unfortunately all remaining *.desktop items were placed into Lost+Found. I expected this result but this will be confusing to less technical users.

Test 4
======

Again simulating a KDE4 user moving to Trinity for the first time, next I manually copied my KDE4 applications-kdemenuedit.menu to applications-tdemenuedit.menu, knowing that the KDE4 custom menu structure is different from Trinity. In addition to reverting instances of TDE->KDE in *.desktop files, I reverted instances of tdesu to kdesu. I again deleted the Trinity profile to force creating a new profile. I did not end up with a Lost+Found submenu, but I did lose my custom Super User submenu. Further, the menu layout was not a Trinity layout, with various menu items out of place from the standard Trinity menu layout.

These last two tests affect only users who have a KDE4 custom menu and no existing Trinity custom menu. I don't know the best way to resolve the problem of all the Lost+Found items or massage the menu layout back to Trinity, but I think we need to address this issue.

After copying and renaming, there likely is a way to massage an existing KDE4 custom menu into a Trinity menu. This would be preferred, even with a few lost menu items, rather than having a long list of items in Lost+Found.

A caveat to the last two tests is I manually copied applications-kdemenuedit.menu to applications-tdemenuedit.menu before starting Trinity. This would not happen in the real world. In the real world the r14-xdg-update script would need to copy an existing KDE4 menu and rename. I will try to run some nominal tests with an amended r14-xdg-update script.

Created attachment 1828 [details]
Proposed r14-xdg-update script (full file)

Updated r14-xdg-update script. Still needs work with migrating a custom KDE4 menu.

Created attachment 1829 [details]
starttde patch to support running r14-xdg-update against a fresh Trinity profile

The caveat I mentioned becomes apparent by a simple fact. When a Trinity profile directly does not exist, then starttde never runs r14-xdg-update. When a new Trinity R14 user already has a custom KDE4 menu, the end result is, and at the moment can only be, a populated Trinity Lost+Found submenu. All of those items in the Lost+Found submenu are desktop items with no place to go because they originated in KDE4 and not Trinity.

One solution is to modify starttde to force run r14-xdg-update against a newly created profile directory. For the most part, running r14-xdg-update does little because the new profile directory is a clean R14 directory. Yet the r14-xdg-update script would be able to handle the Lost+Found problem.

I tested this proposed solution. I modified starttde to force run r14-xdg-update after kpersonalizer runs but only when applications-tdemenuedit.menu exists. The test was successful. I had a new menu with no Lost+Found items.

A remaining problem to solve is to massage the converted KDE4 menu to the layout of Trinity rather than the layout of KDE4. The following menu items are out of place:

Edutainment
Find Files/Folders
Help
Home - Personal Files

All four items are placed at the top of the menu.

I am able to fix the Edutainment and Help layout. I have not figured out how to move the remaining two items to the correct location.

Created attachment 1830 [details]
Proposed r14-xdg-update script (full file)

I believe I solved the remaining menu layout problems. Please refer to comment 8 for testing. Only Test 1, 2, and 3 are needed. To test, tdelibs and tdebase (attachments 1817 & 1829) must be patched as well as using the attached r14-xdg-update script.

In my tests I now have a converted KDE4 menu in the proper Trinity layout with no Lost+Found items.

Created attachment 1832 [details]
Update r14-xdg-update: rename custom menu

When you add rules to r14-xdg-update needs to be updated SCRIPT_VERSION and new / modified rules put in appropriate conditions.

Besides, I made some minor adjustments. I also modified the starttde script so that it may not be specially treated call r14-xdg-update on the new profile.

Please check it out.

>When you add rules to r14-xdg-update needs to be updated SCRIPT_VERSION and new
>/ modified rules put in appropriate conditions.
Yeah, I know --- I did that last night but I was up way too late and did not post the changes here.

>Besides, I made some minor adjustments.
Okay. I have to compare those changes to the most recent adjustments I made very late last night with my testing. I made some more nominal changes since I last updated here based upon additional testing. So I have to merge your changes with mine (that you have not yet seen) and then again retest the different configuration scenarios. I'll update a combined starttde/r14-xdg-update patch after I again perform all the testing. I'll post exactly what I tested and how.

This actually turned into an interesting little problem, but in the end we'll resolve both this bug report and bug 1776.

>I also modified the starttde script so that it may not be specially treated
>all r14-xdg-update on the new profile.
Looks nice.

Created attachment 1833 [details]
Updated r14-xdg-update: rename custom menu

Latest tdebase patch attached.

Here are the environments that I am aware and tested. I am only one use case. A few others should test all of this as best as possible.

Test 1
======
A KDE/TDE 3.5.x user updating to R14 with an existing custom menu.

* Ensure a custom KDE/TDE 3.5.x menu exists.
* Log in to Trinity R14.
* Verify the custom menu name is now applications-tdemenuedit.menu.

Test 2
======
A KDE4 user installing R14.

* Ensure no existing Trinity profile.
* Ensure a custom KDE4 menu exists.
* Start Trinity to create a fresh Trinity profile.
* Verify the new Trinity menu is converted from the KDE4 menu.
* Verify the new menu name is applications-tdemenuedit.menu.
* Verify the layout of the new menu is correct.
* Verify the KDE4 menu is intact.

Test 3
======
A new R14 user or a pre R14 user with no custom menu updating to the latest git or R14.

* Verify no custom menu and no .local/share/applications/*.desktop files.
* Start Trinity.
* Customize the default menu.
* Verify the new custom menu name is applications-tdemenuedit.menu.

Test 4
======
A pre R14 user with an existing custom menu.

* Start with an existing pre R14 profile.
* Verify a custom Trinity menu exists with the old name of applications-kmenuedit.menu.
* Start Trinity.
* Verify the new menu name is applications-tdemenuedit.menu.

I hesitate over the case when applications-kmenuedit.menu corresponds to KDE3/TDE3.5.x - whether in this case, perform a move or copy. If the user updates the KDE3 to KDE4 is converted to KDE4 also the custom menu? In this case, we should do a copy to remained the original KDE3 profile unchanged.

I propose two ways:

__1__Both conditions are merged into one:

if [ ! -f $USER_DIR/.config/menus/applications-tdemenuedit.menu ] && \
   [ -f $USER_DIR/.config/menus/applications-kmenuedit.menu ]; then
  if [ "`grep \"kde4-kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"kde4-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
    Log "  kmenuedit.menu(KDE4)->tdemenuedit.menu"
    # Note: at this point the layout of the renamed KDE4 custom menu will not be the same as Trinity.
    # We'll fix that later.
    cp $USER_DIR/.config/menus/applications-kmenuedit.menu $USER_DIR/.config/menus/applications-tdemenuedit.menu 2>/dev/null
  elif [ "`grep \"kde-kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"kde-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
    # KDE/TDE 3.5.x
    Log "  kmenuedit.menu(KDE)->tdemenuedit.menu"
    cp $USER_DIR/.config/menus/applications-kmenuedit.menu $USER_DIR/.config/menus/applications-tdemenuedit.menu 2>/dev/null
  elif [ "`grep \"tde-Kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"tde-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"tde-Home.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
    # TDE pre R14
    Log "  kmenuedit.menu(TDE)->tdemenuedit.menu"
    mv $USER_DIR/.config/menus/applications-kmenuedit.menu $USER_DIR/.config/menus/applications-tdemenuedit.menu 2>/dev/null
  fi
fi

__2__The first condition is unchanged, the second simplified:

if [ -f $USER_DIR/.config/menus/applications-kmenuedit.menu ]; then
  if [ "`grep \"kde4-kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"kde4-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
     CUSTOM_MENU="KDE4"
  elif [ "`grep \"kde-kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"kde-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
     # KDE/TDE 3.5.x
     CUSTOM_MENU="KDE"
  elif [ "`grep \"tde-Kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"tde-Help.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ] || \
     [ "`grep \"tde-Home.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" ]; then
     CUSTOM_MENU="TDE"
  fi
fi
# Now we know which type of environment. Either copy or move the existing menu.
if [ ! -f $USER_DIR/.config/menus/applications-tdemenuedit.menu ] && \
   [ -f $USER_DIR/.config/menus/applications-kmenuedit.menu ]; then
  Log "  kmenuedit.menu($CUSTOM_MENU)->tdemenuedit.menu"
  if [ "$CUSTOM_MENU" != "TDE" ]; then
    cp $USER_DIR/.config/menus/applications-kmenuedit.menu $USER_DIR/.config/menus/applications-tdemenuedit.menu 2>/dev/null
  else
    mv $USER_DIR/.config/menus/applications-kmenuedit.menu $USER_DIR/.config/menus/applications-tdemenuedit.menu 2>/dev/null
  fi
fi
_____

What is your opinion?

One more note:  I think that the conditions with grep should test whether an empty value is returned. For example:

[ "`grep \"kde4-kfind.desktop\" $USER_DIR/.config/menus/applications-kmenuedit.menu`" != "" ]

Created attachment 1834 [details]
Updated r14-xdg-update: rename custom menu

I discovered a corner case bug. After the menu is renamed and the profile fully updated, should a user decide to run r14-xdg-update manually using the force parameter, any remaining KDE4 *.desktop (OnlyShowIn=KDE) files that were correctly untouched during the automatic update, get updated to KDE->TDE. Then those *.desktop items end up in the Lost+Found submenu. Not good.

I am attaching an updated tdebase patch to fix the problem (if tdemenuedit.menu already exists then set CUSTOM_MENU="TDE", which prevents further execution of updating ~/.local *.desktop files).

I also revised two Log strings to be more technically correct.

>I think that the conditions with grep should test whether an empty value is returned.
I don't know --- what happens when grep returns an empty value in that specific search?

>What is your opinion?
If any users are still using KDE3, and I suppose there are a few, the KDE3 menu is not fully compatible with KDE4. Some examples:

KDE3 uses kde-xxx.desktop
KDE4 uses kde4-xxx.desktop

KDE3 uses Edutainment
KDE4 uses Education

Any person updating from KDE3 to KDE4 and trying to retain the KDE3 custom menu would create a Lost+Found submenu and would notice that Edutainment is misplaced in the menu layout, the same as I experienced during my testing.

I haven't tried testing a KDE3 menu in KDE4 to observe what else might fail.

Should we move or copy a KDE3 menu? I thought about that too. I suppose copying a KDE3 menu is safest with respect to not irritating those still using KDE3.

Therefore my updated patch also merges that section into a single cp, using a single Log message as you suggested:

kmenuedit.menu($CUSTOM_MENU)->tdemenuedit.menu

I've been tackling this bug report for a day and a half, mostly because the testing has to be done just right to simulate conditions. My brain has stopped.

Created attachment 1835 [details]
tdebase patch

Two small corrections:

1) If there not exists tdemenuedit.menu and exists kmenuedit.menu from KDE4, is not copied. It probably was not the intention.

2) CUSTOM_MENU is always set according to kmenuedit.menu regardless of whether it already exists tdemenuedit.menu. This causes repeated adjustments in  tdemenuedit.menu.

Okay. I'll have to dig deep to find the energy to retest all four configuration setups again.

(Odpověď na komentář #20)
> Okay. I'll have to dig deep to find the energy to retest all four configuration
> setups again.

Unfortunately I do not have as good a test environment like yours.
I'll wait for your test results. :)

This is a big system-wide change. Even if others can't test all four configuration scenarios, we should have as many devs as possible testing the scenarios they can actually test.

Testing all four scenarios is a challenge because each environment requires me to think and verify everything I am doing before I start Trinity. The past two days I made lots of pretest mistakes in each environment, not to mention having to stop to fix the script with each test, all of which contributes to the energy drain. :)

I rebuilt tdebase and performed the tests in comment 15. Everything looks okay. I won't be surprised if a user or two presents a corner case issue at some later date, but for now I'm happy.

All patches are pushed to GIT. Due to the omission to update the date-tag in conditions for new rules I had to additionally update r14-xdg-update.

Is it possible to close this bug report?

>Is it possible to close this bug report?
Yes. Thanks for the help!