Tim, Darrell, All,

  In the process of attempting to get the khelpcenter documents all collected in
one spot in 3513-sru, I have found a simple setting that will allow both R14 and
3513-sru to standardize their document locations. The primary issue is that the
base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines
1041-1042:

1041    if (!strcmp(type, "html"))
1042      return "share/doc/kde/HTML/";


  All autotools build packages, on the other hand, set the equivalent path to:

      return "share/doc/HTML/";

  During April (10 & 11), Darrell fixed the R14 document locations. At that time
there was no focus on 3513-sru as a branch. Instead of changing the hardcoded
location in tdelibs to remove ../kde/.. to match all autotools package locations
and changing the CMake files as originally envisioned, hundreds of individual
patches were submitted to change all autotools acinclude.m4 files to move
helpcenter docs from:

kde_htmldir='\${datadir}/doc/HTML'

  to

kde_htmldir='\${datadir}/doc/tde/HTML'

  That works fine for R14, but interjects incompatibility between R14 and 3513
essentially requiring 2-sets of hundreds of patches just to change the
kde_htmldir to '\${datadir}/doc/tde/HTML' (in the case of R14) and to
'\${datadir}/doc/kde/HTML' (for 3513).

  Why not fix this once and for all, fix tdelibs, and just set:

kde_htmldir='\${datadir}/doc/HTML'

for all??

  That way, instead of patching hundreds of autotools packages, the original
location in tdelibs is standardized where it should be in 'kstandarddirs.cpp',
the CMake files are corrected to match the original kde_htmldir locations in
their sources, and all future CMake migration can go forward without every set
of files having to set kde_htmldir and reset it for 3513 in another set of
patches... (this stuff should be standard anyway -- there is absolutely no need
to have 'kde' or 'tde' in the middle of kde_htmldir)

  This would eliminate hundreds of patches required to change to 'tde' for R14
and to 'kde' for 3513 and move all sources back closer to their pristine state.
This couldn't have been envisioned in April, but if we are serious about
providing a 3513-sru branch and R14, then I think this is the right way to do it.

  See: http://www.trinitydesktop.org/patches/  The set of commits at issue are
between the following:

398ef116	2012-04-10
4e430ec6	2012-04-11

  Thoughts?

-- 
David C. Rankin, J.D.,P.E.