On Sunday 07 of October 2012 19:33:47 Darrell Anderson wrote:
> > I've combined your patch with my modification. Instead of
> > renaming based on the existence of binaries, I introduced a variable
> > TDE_REBRAND.
> >
> > What do you think about it?
>
> Looks fine to me. Go ahead and push. :)
>
> I was concerned about using tde-config because of the original bugs
> that created profile directories in the system root or in the user's
> $HOME. Looking at the 3.5.13.1 change log indicates the related patches
> were backported to 3.5.13.1 in kde-config, so I think we're safe.
>
> If somebody is using 3.5.10 - 3.5.13, the original kde-config will not
> have been patched, but with the migratekde3 patching these config file
> renaming snippets will not execute anyway. Further, previously I added
> a snippet to use konqueror to determine the version rather than
> kde-config for those older Trinity versions.
>
> I still have my 3.5.10 profiles, which I use to test migratekde3. I
> don't have 3.5.11 -> 3.5.13 profiles. Hopefully before R14 is released
> others with those previous Trinity versions will have tested
> migratekde3.
>
> We have to be careful to keep migratekde3 and r14-xdg-update unique.
> They serve two different purposes and we don't want overlap. For
> example, my recent patch to support Quanta Plus plugins.rc in
> r14-xdg-update. That involved renaming but the renaming occurred in the
> R14 development.
>
> Darrell
>
Pushed in GIT hash ad8633f6.
I understand - in startkde is also instead of kde-config used konqueror.
Also I understand the reasons to keep a separate script for migration
from KDE3 and migration XDG.
I have another suggestion for change. During the search in the profile is
treated, they are not searched folders in kmail/mail. But the same is
necessary for folders dimap, imap and also autosave. On the folder
kmail/search I'm not sure. Proposed patch attached.
Next, I wanted to ask whether we can assume the presence of xargs on the
users machines? It can in the replacement lower overhead of repeated
execution sed and thus increase the speed. For example:
find $HOME/.trinity \
-path $HOME/.trinity/share/apps/kmail/autosave -prune -o \
-path $HOME/.trinity/share/apps/kmail/dimap -prune -o \
-path $HOME/.trinity/share/apps/kmail/imap -prune -o \
-path $HOME/.trinity/share/apps/kmail/mail -prune -o \
-path $HOME/.trinity/share/apps/kmail/search -prune -o \
-type f -print0 | \
xargs -r0 sed -i "s|/opt/kde/|${TDEDIR}/|g"
Instead of launching many sed, how much will be files, can be run only one
sed, which will process all files that are found.
What is your opinion on this?
Slavek
--
Attachments: