18 Jul
2012
18 Jul
'12
1:03 a.m.
I see a potential snag. Your 3.5.12 profile directory
is
named $HOME/.kdemod3. I believe Arch had started KDE3 mod
before Trinity started. The migratekde3 script does not look
for that specific name because I never knew about that name,
but I'll update the script. I think a 3.5.12 profile is
essentially a KDE3 profile. If true then I'll do some
testing here copying a $HOME/.kde3 profile to $HOME/.trinity
and see what breaks.
I always ran the migratekde3 script and you probably never
have. I'm wondering what happens when you run the
migratekde3 script against your 3.5.12 profile. Perhaps that
fixes a lot, some of which the r14-xdg-update script does
not touch. If you want to test the migratekde3 script you
can temporarily edit the script to look for $HOME/.kdemod3
rather than $HOME/.kde3.
David,
I pushed a patch to update the migratekde3 script to include $HOME/.kdemod3 as a KDE3
profile directory. You don't need to rebuild tdebase. Just 'git pull' tdebase
and then copy the file from the sources to $PREFIX/bin/.
Because no renaming changes occurred until 3.5.13 and thereafter, I am treating 3.5.12
profile directories as essentially KDE3 profiles. Therefore you might want to test the
migratekde3 script against your $HOME/.kdemod3 profile. The script will create a
$HOME/.trinity profile along with appropriate scrubbing. The r14-xdg-update script is run
once from within starttde and performs a different set of scrubbing.
Make sure your kdeglobals does not contain an [R14 XDG Updates] key group or
r14-xdg-update won't run when you start TDE.
If the migratekde3 script helps you, then we will need to figure out how to automate
running migratekde3 against pre 3.5.13 profiles. The challenge is the script is not
designed to run against an existing Trinity profile. I started to look into that and
things got messy.
Darrell