stderr when selecting the Help button:

KCHMSetupDialog::slotShowHelp(): Not implemented yet

Fixed in Debian/Ubuntu with commit 3033b33.

Darrell, after the fix, if I press the Help button in the KChmviewer settings dialog window, the KChmviewer "we apologize" handbook template is correctly displayed.
Do you still have the problem in Slackware or is it now ok (perhaps following previous fixes)?
Thanks.

I also tested running from command line. The message "KCHMSetupDialog::slotShowHelp(): Not implemented yet" does not appear.

Waiting your feedback before closing the bug.

>Fixed in Debian/Ubuntu with commit 3033b33.
I do not find any such commit after updating my source tree. A quick rebuild this morning of only kchmviewer indicates the same bugs.

Created attachment 2059 [details]
kchmviewer patch

>> Fixed in Debian/Ubuntu with commit 3033b33.
> I do not find any such commit after updating my source tree.
Commit 3033b33 is for the packaging repo, not the main repo, and it is specific for Debian/Ubuntu distros.
In Debian/Ubuntu, KChmviewer handbook was being installed in /usr/share instead of /opt/trinity/share. After fixing that, everything was ok: the template handbook is correctly displayed whether it is called from Help->KChmviewer handbook or from the settings dialog's help button.

1) What happen when you try Help->KChmviewer handbook? Is the template handbook shown?
2) What happen is you type "khelpcenter help:kchmviewer" from the command line?
3) can you try the attached patch as well and tell me if it fixes the problem? It works fine in Debian/testing, but as said, it was working fine even without the patch (I tried from all 3 tabs of the setting dialog).

>1) What happen when you try Help->KChmviewer handbook?
Works fine.

>2) What happen is you type "khelpcenter help:kchmviewer" from the command line?
Works fine.

>3) can you try the attached patch as well and tell me if it fixes the problem?
The Help button in Settings (all 3 tabs) still does nothing. Same error as reported in comment 1.

Build configuration:

CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
  --prefix=${PREFIX} \
  --sysconfdir=${SYSCONFDIR} \
  --libdir=${LIBDIR} \
  --mandir=${MANDIR} \
  --with-qt-dir=${QTDIR} \
  --with-qt-includes=${QT_INCLUDE_DIR} \
  --with-qt-libraries=${QT_LIB_DIR} \
  --with-kde \
  $DEBUG_AUTOTOOL_OPT || exit 1

Thanks for the feedback Darrell. Interesting behavior indeed.
Could you upload your build log? I will have a look through.
For you reference, here is how configure is invoked on my system:

mkdir build-kde && cd build-kde && ../configure CFLAGS="-Wall -g -O2" --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/opt/trinity --with-extra-libs=/opt/trinity/lib --includedir=/opt/trinity/include/tde --mandir=/opt/trinity/share/man --with-qt-dir=/usr/share/qt3 --sysconfdir=/etc --infodir=/opt/trinity/share/info --disable-debug --disable-rpath --with-kde

Created attachment 2060 [details]
kchmviewer build log

Thanks.

Hi Darrell,
I haven't had the time to have another look at this bug yet, but it would be a lot helpful if you could do the following test and upload the resulting file.

1) build KChmviewer with debug info (use the --enable-debug switch instead of --disable-debug)
2) install the built file, run 'gdb kchmviewer'. You should see a message like 'Reading symbols from /opt/trinity/bin/kchmviewer...done.'.
Then type 'list KCHMSetupDialog::slotShowHelp' and you should see the source code of such function. Exit gdb.
3) if all is ok, run the following command from command line
'valgrind valgrind --dsymutil=yes --tool=callgrind kchmviewer'
4) when KCHmviewer opens, select a file to view, then click 'Settings -> Change settings...' and in the dialog that opens click the Help button once. Then click on the 'Advanced' tab in the dialog and click again on the Help button. Finally close the dialog and exit Kchmviewer.
5) In the folder from which you run 'valgrind....' you will find a 'callgrind.out.<pid>' file, it's quite big (several MB). Please compress the file and upload it.

That should provide helpful information about what's going on when you press the help button.

In comment 6 where I shared my configuration options, $DEBUG_AUTOTOOL_OPT is set to  --enable-debug=full.

Here is the output:

=================================
gdb kchmviewer
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/trinity/bin/kchmviewer...done.
(gdb) list KCHMSetupDialog::slotShowHelp
392     kchmsetupdialog.cpp: No such file or directory.
(gdb) q
=================================

I did not see any symbols loading.

Thanks Darrell,
gdb actually loaded the debugging symbols (see line Reading symbols). The fact that it can't find the source code for listing is not crucial (we could fix that but it is not what I am after).
Could you do the valgrind test and upload the resulting file?
Thanks.
PS: I just noticed there was a repetition in the original valgrind command I posted. The correct command is: 'valgrind --dsymutil=yes --tool=callgrind kchmviewer'

>Then type 'list KCHMSetupDialog::slotShowHelp' and you should see the source 
>code of such function. Exit gdb.
My output shows no source code.

I quit gdb before running valgrind. I attempted to use the Settings Help button while valgrind was running. This is the only output I saw:

valgrind --dsymutil=yes --tool=callgrind kchmviewer

==26796== Callgrind, a call-graph generating cache profiler
==26796== Copyright (C) 2002-2012, and GNU GPL'd, by Josef Weidendorfer et al.
==26796== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==26796== Command: kchmviewer
==26796==
==26796== For interactive control, run 'callgrind_control -h'.
KCHMSetupDialog::slotShowHelp(): Not implemented yet
==26796==
==26796== Events    : Ir
==26796== Collected : 1360569722
==26796==
==26796== I   refs:      1,360,569,722

(In reply to Darrell from comment #13)
> I quit gdb before running valgrind. I attempted to use the Settings Help button
> while valgrind was running. This is the only output I saw:
Thanks Darrell, well done. That's all correct, including the output that you saw on the terminal.
If you look in the folder where you run valgrind from, you should now have a file named 'callgrind.out.26796' (notice that 26796 is the pid that valgrind printed on the screen). That's the file that I need. It should be very big, but it you compress it, the size should be quite ok (in my case I went from 5 Mb to 150 kb or so).
If you have deleted it already, it is sufficient to rerun valgrind with the same syntax. In such case the pid will most likely be different, and so the name of the callgrind.out file

Created attachment 2069 [details]
Valgrind output (compressed xz)

Valgrind output. Includes attempting to open the help file from the Settings Help button.

Thanks Darrell,
I will take a look at this bug either later this week or next week.

Darrell,
the build log and the Valgrind output were very useful, I was even able to replicate the problem on my computer.
The problem has been fixed in commit a6711dd.

The problem was exposed only in in-source building, while out-of-source building did not suffer the same problem.

Before I mark the bug as resolved, please check that everything is fine also on your side, I believe it should :)
Do not use any patch, it is not needed anymore.

I don't understand the distinction between in/out-of-source builds with automake, but the bug seems fixed. Good job. Thank you.

> I don't understand the distinction between in/out-of-source builds with
> automake, but the bug seems fixed. Good job. Thank you.
In Debian the package is built as follow:

[ -d build-kde ] || mkdir build-kde
cd build-kde && ../configure CFLAGS="$(CFLAGS)" $(CONFIGURE_OPTIONS_TDE)
$(MAKE) -C build-kde

So all the build files are inside the build-kde, similarly to what we do with when using cmake and building in the obj_xxxxxxx folder

The KCHMSetupDialop.cpp was being recreated at runtime from the corresponding .ui file. In Debian that was not causing any problem, because the recreated file was going into the build-kde folder. Without using the build-kde folder, the recreated file was overwriting the KCHMSetupDialop.cpp in the src folder, exposing the bug that you noticed.

Thanks for the support in testing.