Slavek, Darrell
Slavek, We need to FIX the khelpcenter manuals. Most of them are missing. Darrell, since you seem intimately familiar with getting them to work, what do we need to look for? What is strange is that in some groups -- some are there and some are not. I'm not sure what to make of that.
I've taken the time to summarize the application manuals that are missing from khelpcenter in 3513-sru. I have opened http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=1178 to resolve this.
Application Manuals Development <all missing> Edutainment <all missing> Games <all missing> Graphics <all missing> Internet Knetload Network Monitor - <missing> Multimedia K3b - <missing> Kaffeine -<missing> Kmix - <missing> KMplayer - <missing> Office kbarcode - <missing> kexi - <missing> kfromula - <missing> kivia - <missing> koffice - <missing> koffice workspace - <missing> kplato - <missing> kpresenter - <missing> kspread - <missing> ksugar - <missing> ksugar designer - <missing> kword - <missing> Settings wallet management tools - <missing> Settings-Modules Hardware Display - <missing> ICC Color Profile - <missing> Laptop Battery - <missing> Remote Controls - <missing> Security & Privacy KDE Wallet - <missing> System Administration IBM Thinkpad Laptop - <missing> Monitor & Display - <missing> Sony Vaio Laptop - <missing> System Dolphin - <missing> Kcron - <missing> Kdat - <missing> Kdiskfree - <missing> KNutClient - <missing> KPackage - <missing> Krusader-root-mode - <missing> KsysV - <missing> KUser - <missing> KwickDisk - <missing> ScreenSavers - <missing> Utilities Accessibility <all missing> Ark - <missing> KbookReader - <missing> Desktop SuperKaramba - <missing> Editors KEdit - <missing> IRKick - <missing> KCalc - <missing> KCharSelect - <missing> KDirstat - <missing> KFileReplace - <missing> KFloppy - <missing> KHexEdit - <missing> KMobile - <missing> KRegExpEditor - <missing> Krename - <missing> Krusader - <missing> PIM KGpg - <missing> Kjots - <missing> Ksig - <missing> Toys <all missing>
Darrell, since you seem intimately familiar with getting them to work, what do we need to look for? What is strange is that in some groups -- some are there and some are not. I'm not sure what to make of that.
Read my comments in bug report 1178.
Darrell
On 08/18/2012 08:59 AM, Darrell Anderson wrote:
Read my comments in bug report 1178.
Darrell
Thank you!
I'll pick through the mess as soon as I recover from a 7 and two 9 year-old sleepover last night..... Very painful....
On 08/18/2012 04:22 PM, David C. Rankin wrote:
On 08/18/2012 08:59 AM, Darrell Anderson wrote:
Read my comments in bug report 1178.
Darrell
Thank you!
I'll pick through the mess as soon as I recover from a 7 and two 9 year-old sleepover last night..... Very painful....
Here is the current doc install situation in 3513:
/opt/trinity/share/doc HTML/en -- BAD <majority missing apps are here> kde/HTML/en --OK ksquirrel-libs -- BAD tde/HTML/en -- BAD abakus krename
Basically the working docpath in 3513 is:
/opt/trinity/share/doc/kde/HTML/en
all other locations are not included in khelpcenter. The incorrectly installed documents account for more than 50% of the application manuals.
Slavek, should we consider /opt/trinity/share/doc/kde/HTML the standard docpath in 3513-sru? If so I'll look at creating patches.
Le 19/08/2012 08:46, David C. Rankin a écrit :
On 08/18/2012 04:22 PM, David C. Rankin wrote:
On 08/18/2012 08:59 AM, Darrell Anderson wrote:
Read my comments in bug report 1178.
Darrell
Thank you!
I'll pick through the mess as soon as I recover from a 7 and two 9 year-old sleepover last night..... Very painful....
Here is the current doc install situation in 3513:
/opt/trinity/share/doc HTML/en -- BAD <majority missing apps are here> kde/HTML/en --OK ksquirrel-libs -- BAD tde/HTML/en -- BAD abakus krename
Basically the working docpath in 3513 is:
/opt/trinity/share/doc/kde/HTML/en
all other locations are not included in khelpcenter. The incorrectly installed documents account for more than 50% of the application manuals.
Slavek, should we consider /opt/trinity/share/doc/kde/HTML the standard docpath in 3513-sru? If so I'll look at creating patches.
I agree that all packages should have the same default HTML directory location, that would work by default. But I think we should not hardcode a "kde" directory now in GIT, since we are trying to get rid of kde references.
Currently in 3.5.13, it looks like all cmake-built (including tdelibs ...) packages default to "doc/kde/HTML", whereas autotools-built default to "doc/HTML". Most applications still use autotools, that's why their HTML directory is not consistent with tdelibs.
To avoid this, I hardcode the directory directly in the build process in autotools-built packages. Something like: sed -i admin/acinclude.m4.in -e "s|kde_htmldir='.*'|kde_htmldir='/opt/trinity/share/doc/kde/HTML'|g"
This is a just a workaround until we take a final decision.
Francois
On 08/19/2012 02:26 AM, Francois Andriot wrote:
To avoid this, I hardcode the directory directly in the build process in autotools-built packages. Something like: sed -i admin/acinclude.m4.in -e "s|kde_htmldir='.*'|kde_htmldir='/opt/trinity/share/doc/kde/HTML'|g"
This is a just a workaround until we take a final decision.
Francois
Agreed,
At present, I just want the help system working. I can look at modifying my build scripts to get the application manuals in the right place.
Historically, I can see a reason you would want all core kde apps in:
/opt/trinity/share/doc/kde/HTML/<language>
while wanting 3rd party apps somewhere else like:
/opt/trinity/share/doc/HTML/<language>
But today, I just think that makes a mess out of things. To be consistent and provide seamless interoperability between R14 and 3513, it makes sense to just use:
/opt/trinity/share/doc/HTML/<language>
My big question is where is this initially set? tdelibs sounds like it sets the base docpath that everything else must follow. So we have to get tdelibs set, then point everything else to the same place. Are there any other considerations there?
Le 19/08/2012 18:24, David C. Rankin a écrit :
On 08/19/2012 02:26 AM, Francois Andriot wrote:
To avoid this, I hardcode the directory directly in the build process in autotools-built packages. Something like: sed -i admin/acinclude.m4.in -e "s|kde_htmldir='.*'|kde_htmldir='/opt/trinity/share/doc/kde/HTML'|g"
This is a just a workaround until we take a final decision.
Francois
Agreed,
At present, I just want the help system working. I can look at modifying my build scripts to get the application manuals in the right place.
Historically, I can see a reason you would want all core kde apps in:
/opt/trinity/share/doc/kde/HTML/<language>
while wanting 3rd party apps somewhere else like:
/opt/trinity/share/doc/HTML/<language>
But today, I just think that makes a mess out of things. To be consistent and provide seamless interoperability between R14 and 3513, it makes sense to just use:
/opt/trinity/share/doc/HTML/<language>
My big question is where is this initially set? tdelibs sounds like it sets the base docpath that everything else must follow. So we have to get tdelibs set, then point everything else to the same place. Are there any other considerations there?
The default path is set in kdelibs in file: cmake/modules/TDESetupPaths.cmake Look for variable HTML_INSTALL_DIR .
But you should also be able to specify a different path at build time for each package, for instance: cmake -DHTML_INSTALL_DIR=/opt/trinity/share/doc/HTML
Francois
On 08/19/2012 11:31 AM, Francois Andriot wrote:
My big question is where is this initially set? tdelibs sounds like it sets the base docpath that everything else must follow. So we have to get tdelibs set, then point everything else to the same place. Are there any other considerations there?
The default path is set in kdelibs in file: cmake/modules/TDESetupPaths.cmake Look for variable HTML_INSTALL_DIR .
But you should also be able to specify a different path at build time for each package, for instance: cmake -DHTML_INSTALL_DIR=/opt/trinity/share/doc/HTML
Francois
Thank Francios,
That works for cmake apps, but for autotools apps, I am having to fix the ones that don't go in the correct spot at build time with sed like:
## fix doc install location msg "Patching datadir location share/doc/kde/HTML ..." sed -i 's|doc/HTML|doc/kde/HTML|' ${pkgname#*-}/admin/acinclude.m4.in
That will set kde_htmldir to:
kde_htmldir='${datadir}/doc/kde/HTML'
That works with the current tdelibs setting. Once we get a decision on whether to move 3.5.13-sru to ${datadir}/doc/HTML or leaving it as it is ${datadir}/doc/kde/HTML we can make it consistent in the GIT tree for both cmake and autotools applications.
As Darrell pointed out, the hardcoding occurs in tdelibs/kdecore/kstandarddirs.cpp on line 1042:
TQString KStandardDirs::kde_default(const char *type) { if (!strcmp(type, "data")) return "share/apps/"; if (!strcmp(type, "html-bundle")) return "share/doc-bundle/HTML/"; if (!strcmp(type, "html")) 1042 return "share/doc/kde/HTML/";
Unless we are going to patch/change the location in kstandarddirs.cpp, then I think we make that the default or all packages. The location just has to be consistent. From what I can tell, all of the cmake packages are putting the docs there. That means we will have to either patch, or handle build-time fixing for all autotools packages admin/acinclude.m4.in files. (that seems stupid, but unless we do that, we won't have help files in khelpcenter)
Since I looks like most all autotools files already put doc files in share/doc/HTML/<lang>, it seems to make much more sense just to fix tdelibs to install in the same place. If I understand correctly, the single change in tdelibs from:
return "share/doc/kde/HTML/"; to return "share/doc/HTML/";
would fix the majority of the problem and be consistent for both R14 and 3513 eliminating the need for any 't'de or 'k'de between /doc/../HTML. Here are the current autotools docs installed in doc/HTML:
18:04 tdesru:/opt/trinity/share/doc/HTML/en> l1 amor ark atlantik basket blinken bookreader cervisia chalk doc filelight gwenview irkick k3b k9copy kaffeine kalzium kanagram karbon kasteroids katapult kate-plugins katomic kbabel kbackgammon kbattleship kblackbox kbounce kbruch kbugbuster kcachegrind kcalc kcharselect kchart kcmlirc kcontrol kcron kdat kdesvn kdesvn-build kdf kdiff3 kdirstat kdmtheme kedit keduca kenolaba kexi kfloppy kformula kfouleggs kgeography kgoldrunner kgpg khangman khexedit kicker-applets kig kima kinfocenter kipi-plugins kiten kivio kjots kjumpingcube klatin klettres klickety klines kmag kmahjongg kmines kmoon kmousetool kmouth kmplayer kmplot knetstats knetworkconf knutclient kodo koffice kolf kompare konq-plugins konquest konversation koshell kpackage kpat kpercentage kplato kpoker kpresenter KRegExpEditor kreversi krusader ksame kshisen ksig ksim ksirtet ksmiletris ksnake ksokoban kspaceduel kspread kstars ksysv kteatime ktimer ktouch ktron kttsd ktuberling kturtle kugar kuser kverbos kvoctrain kwallet kweather kwin4 kword kwordquiz kworldclock lilo-config lskat superkaramba thesaurus umbrello
I don't know why R14 continues to use 'return "share/doc/tde/HTML/";'?
Darrell, would dropping the tde/kde from tdelibs/tdecore/kstandarddirs.cpp work for R14??
Dne po 20. srpna 2012 David C. Rankin napsal(a):
Thank Francios,
That works for cmake apps, but for autotools apps, I am having to fix the ones that don't go in the correct spot at build time with sed like:
## fix doc install location msg "Patching datadir location share/doc/kde/HTML ..." sed -i 's|doc/HTML|doc/kde/HTML|' ${pkgname#*-}/admin/acinclude.m4.in
That will set kde_htmldir to:
kde_htmldir='${datadir}/doc/kde/HTML'
That works with the current tdelibs setting. Once we get a decision on whether to move 3.5.13-sru to ${datadir}/doc/HTML or leaving it as it is ${datadir}/doc/kde/HTML we can make it consistent in the GIT tree for both cmake and autotools applications.
I looked in the tde-packaging. For Debian and Ubuntu is kde_htmldir set to ${datadir}/doc/kde/HTML at build:
export kde_htmldir = $${datadir}/doc/kde/HTML
That's why I did not notice absence of documentation.
So what solution we choose? Reason to use kde/tde in the name of the folder, as Darrell said in the other thread, seem to me correct. A suitable seem only these solutions:
a) Solve it at build time (as it is in Debian/Ubuntu) b) Backport patches between 398ef116 and 4e430ec6 into v3.5.13-sru branch
Some other solution? What is your opinion?
Slavek --
On 08/21/2012 09:56 AM, Slávek Banko wrote:
b) Backport patches between 398ef116 and 4e430ec6 into v3.5.13-sru branch
After thinking though the issue and a future /usr install, this is the correct way to do it. We can just standardize on the R14 location of /doc/tde/HTML and that works for the whole GIT tree.
I like it! Can you do it?
Dne út 21. srpna 2012 David C. Rankin napsal(a):
On 08/21/2012 09:56 AM, Slávek Banko wrote:
b) Backport patches between 398ef116 and 4e430ec6 into v3.5.13-sru branch
After thinking though the issue and a future /usr install, this is the correct way to do it. We can just standardize on the R14 location of /doc/tde/HTML and that works for the whole GIT tree.
I like it! Can you do it?
Ok, patches, that I had unfinished I have now finished so I can go to integrating a patches to change the path of documentation.
I suggest, before I start with that, prepare v3.5.13-sru branch on meta-project 'tde'. What do you think? I would say that it is the appropriate time. :)
Slavek --
Here is the current doc install situation in 3513:
/opt/trinity/share/doc HTML/en -- BAD <majority missing apps are here> kde/HTML/en --OK ksquirrel-libs -- BAD tde/HTML/en -- BAD abakus krename
Basically the working docpath in 3513 is:
/opt/trinity/share/doc/kde/HTML/en
all other locations are not included in khelpcenter. The incorrectly installed documents account for more than 50% of the application manuals.
Slavek, should we consider /opt/trinity/share/doc/kde/HTML the standard docpath in 3513-sru? If so I'll look at creating patches.
The default install locations are hard-coded in (k)tdelibs/(k)tdecore/kstandarddirs.cpp. The make files must match.
Darrell
-
Darrell Anderson -
David C. Rankin -
Francois Andriot -
Slávek Banko