18 Aug
2012
18 Aug
'12
4:41 a.m.
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>
--
David C. Rankin, J.D.,P.E.
18 Aug
18 Aug
1:59 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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
9:22 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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....
--
David C. Rankin, J.D.,P.E.
19 Aug
19 Aug
6:46 a.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
On 08/18/2012 04:22 PM, David C. Rankin wrote:
On 08/18/2012 08:59 AM, Darrell Anderson wrote:
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.
--
David C. Rankin, J.D.,P.E.
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....
7:26 a.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
Le 19/08/2012 08:46, David C. Rankin a écrit :
On 08/18/2012 04:22 PM, David C. Rankin wrote:
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/18/2012 08:59 AM, Darrell Anderson wrote:
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.
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....
4:24 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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?
--
David C. Rankin, J.D.,P.E.
4:31 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
Le 19/08/2012 18:24, David C. Rankin a écrit :
On 08/19/2012 02:26 AM, Francois Andriot wrote:
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
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?
11:10 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
On 08/19/2012 11:31 AM, Francois Andriot wrote:
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??
--
David C. Rankin, J.D.,P.E.
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 
21 Aug
21 Aug
2:56 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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
--
5 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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?
--
David C. Rankin, J.D.,P.E.
27 Aug
27 Aug
7:05 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
Dne út 21. srpna 2012 David C. Rankin napsal(a):
On 08/21/2012 09:56 AM, Slávek Banko wrote:
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
--
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?
19 Aug
19 Aug
5:54 p.m.
New subject: [trinity-devel] WHOA - 3513-sru 'Most' KHelpCenter App Manuals - MISSING (Bug 1178)
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
4265
days inactive
4274
days old
11 comments
4 participants
participants (4)
-
Darrell Anderson -
David C. Rankin -
Francois Andriot -
Slávek Banko