Bug 1850

Sounds like an interesting bug to look at, and one that could affect TDE reviews in the wrong way :(

I will work on this after I am done with bug 1857.
If anyone wants to have a go at this bug before that, feel free to reassign the bug.

I discovered this bug while working on the help handbooks. I noticed there are several handbooks that could not be accessed, all of which were related to kcontrol modules.

Resolution requires ensuring each module has a direct line to a respective handbook, or a handbook bookmark. Many kcontrol modules have no tabs, but even some of them are affected as reported in several bug reports.

Handbook paths are defined in the module's respective *.desktop file, through the DocPath key.

All multiple tab modules can be opened individually, either from the Settings menu or through the tdecmshell command. Each module needs to be able to find the respective handbook using the *.desktop DocPath key.

Note that some modules don't have full handbooks. Instead they need to open a parent handbook at a specific bookmark. The resolution need only ensure the DocPath key is used.

When kcontrol modules are not opened individually but opened in kcontrol and displayed through tabs, then the master kcontrol Help button needs to work in coordination with the module's *.desktop DocPath. Currently, regardless of which tab is slected, the Help button always opens the handbook of the first tab.

This is not a Trinity problem. Trinity inherited this bug. The bug has existed since KDE3.

I am setting the status back to NEW temporarily.
I have bug 1857, kate syntax highlight (including bug 1946) and a follow up of bug 1825 to clear first.
I will be back to this bug later.

Been working on this; should have a fix shortly.

I have added a mechanism by which sections of docbooks may be automatically opened based on the active TDEControl module tab in GIT hashes 319f69a (tdelibs) and 88a2e25 (tdebase).  I have also fixed a number of tabbed TDEControl modules and related docbooks in that same commit to provide a good set of examples that others may draw upon when converting the remaining tabbed TDEControl modules.

This is a perfect bug for anyone with limited C++ knowledge to work on.  All that needs to be done at this point is to find any modules with a TQTabWidget and multi-section docbook.  Open the docbook and note the sect2 IDs (if there are sect2 tags without IDs specified please add sensible IDs to those tags); these are the strings you will assign to each tab number in the new handbookSection() method of the associated TDEControl module.

I would convert the rest myself, but this was starting to feel like somewhat repetitive work that 1.) others could handle and 2.) was taking time away from bugs that others cannot handle. ;-)

For reference, a list of kcontrol modules with tabs:

Appearance & Themes
-------------------
Icons (Fixed)
Style
Window Decorations (Partially fixed, docbook is missing sections and can't test fully)

Desktop
-------
Behavior (Fixed)
Panels
Window Behavior (Fixed)

Internet & Network
------------------
Desktop Sharing
Local Network Browsing
Local Network Chat
Network Settings
Proxy
Samba
Samba Status
Web Browser->Cookies
Web Browser->Java & JavaScript
Wireless Network
Zeroconf Service Discovery

Peripherals
-----------
Display
Laptop Battery
Mouse
Remote Controls
Storage Media

Regional & Accessibility
------------------------
Accessibility
Country/Region & Language
Keyboard Layout
Keyboard Shortcuts
Text-to-Speech


Security & Privacy
------------------
Crypto
TDE Wallet

Sound & Multimedia
------------------
Audio CDs
CDDB Retrieval
Sound System

System Administration
---------------------
Boot Manager (LILO)
Login Manager
Monitor & Display

TDE Components
--------------
File Manager
TDE Performance

Is anyone working on this report?

If anyone does have intention of doing so, please assign the report to yourself so that we can avoid duplication of effort.  There aren't many R14 blocker bugs left at this point so the chances of a collision are very high.

>Is anyone working on this report?
>If anyone does have intention of doing so, please assign the report to yourself >so that we can avoid duplication of effort.  There aren't many R14 blocker bugs >left at this point so the chances of a collision are very high.
I can work on this when I am done with bug 1859. Considering the time that I have available, I don't expect to be able to start before at least a week.
If anyone else want to work on it before that time, feel free to go ahead.
I will assign the bug to myself only when I actually start working on it.

"Appearance and Themes" and "Desktop" are fully converted as of GIT hash cc12a51.  I might continue with the "Internet & Network" category, so if anyone else wants to help out (assistance would be appreciated!) please choose a different category to work on.

Thanks!

(In reply to Timothy Pearson from comment #9)
> "Appearance and Themes" and "Desktop" are fully converted as of GIT hash
> cc12a51.  I might continue with the "Internet & Network" category, so if
> anyone else wants to help out (assistance would be appreciated!) please
> choose a different category to work on.
> 
> Thanks!

"Internet & Network" is fully converted as of GIT hashes 0014712 (tdebase), 2cffbbc (tdenetwork), and bd1f9be (tdeadmin).

I will be working on other reports and tasks for a while; please feel free to take my commits as an example and convert the remaining sections!

Michele can you work on this after you finish with Bug 1859?  Just post a comment with the category or categories you are converting so that we can avoid duplication of effort as I will probably be poking at this as I have time.

Thanks!

> Michele can you work on this after you finish with Bug 1859? 
Yes, no problem. That was already my intention.

(In reply to Michele Calgaro from comment #12)
> > Michele can you work on this after you finish with Bug 1859? 
> Yes, no problem. That was already my intention.

Now that Bug 1859 is closed do you have time to work on this report?  I ask as R14 release is looming large in a short period of time; RC1 is almost ready at this point.

Thanks!

>Now that Bug 1859 is closed do you have time to work on this report?  I ask as 
>R14 release is looming large in a short period of time; RC1 is almost ready at 
>this point.
Hi Tim,
I haven't been very active in the last month due to a bigger workload that does not leave me a lot of spare time. As you have seen, I haven't put in a lot of commits recently. I wish I had more free time, but at the moment I simply have too many things going on together.
I am planning to work on this bug, possibly starting this week.

Anyhow IMO we do not need to block R14 because of this bug. Broken "tab help buttons" have been there since the KDE days. If some buttons are not fixed by the time R14 is ready, they can be fixed in subsequent v14.0.x maintenance releases (probably v14.0.1). What do you think?

Tim,
I started to have a look on this bug. But I see something quite strange. For example you mentioned that "Appearance and Themes" and "Desktop" are fully converted. But when I click on the "help" button on the bottom of the screen, nothing happens and no help file is open.
It's a recent build, just 7 days old, so all the changes you made were definitely compiled. 
Do you (or anyone else) see the same behavior? Does the help handbook open on your system?

Sorry, I forgot to mention that I see the same problem on TDE Control modules that have either a single tab or multiple tabs.

Strange; I know this was working when I committed it (and for some time after), but testing on the latest builds indicates the help system now will not launch at all.

Question is, what changed regarding the help system over the past month or so?

It looks like launching from within kcontrol shows the problem; launching via tdecmshell does not.  For now use tdecmshell to test with while I work on the kcontrol problem.

> It looks like launching from within kcontrol shows the problem; launching via > tdecmshell does not.
Lauching from tdecmshell and pressing "help" does open the helpcenter. But no handbook is invoked. Whatever module I run I get the "no documentation found" page and a quite ps -aux check reveals that the helpcenter is invoked without any parameter (I get "khelpcenter help:/").
Do you also see this problem, or on your system you actually get the correct help handbook to open?

(PS: it's sleep time for me now, I will check back tomorrow).
Thanks!

(In reply to Michele Calgaro from comment #19)
> > It looks like launching from within kcontrol shows the problem; launching via > tdecmshell does not.
> Lauching from tdecmshell and pressing "help" does open the helpcenter. But
> no handbook is invoked. Whatever module I run I get the "no documentation
> found" page and a quite ps -aux check reveals that the helpcenter is invoked
> without any parameter (I get "khelpcenter help:/").
> Do you also see this problem, or on your system you actually get the correct
> help handbook to open?
> 
> (PS: it's sleep time for me now, I will check back tomorrow).
> Thanks!

I think I might know what did this...I brought the doc handbook desktop file entries into XDG specifications but kcontrol might not be reading the files correctly.  Let me check.

Ok, no rush. Till Monday I won't be able to work on it anyway.

(In reply to Michele Calgaro from comment #21)
> Ok, no rush. Till Monday I won't be able to work on it anyway.

It's now fixed in GIT so you should be able to start work on it when you next have time available.

Thanks!

> It's now fixed in GIT so you should be able to start work on it when you next 
> have time available.
Good, thanks. I will make a rebuild tomorrow. I am expecting to have some time this week if nothing unusual happens, so I should be able to do some work on this.

I confirm it is now working again, thanks. I will be working on this during the week

I will work on the Regional & accessibility section this week. Feel free to work on other sections if you want.

The Regional & Accessibility section is now ready (but not pushed). I will move to the Security & Privacy next.

Tim, what's your preference for pushing to GIT? Push whenever one section is complete or just one big push at the end when all sections are ready?

Commit each section but due to the fact that we are in a release candidate cycle you will need to wait to push until the next merge window.

Tim

> Commit each section but due to the fact that we are in a release candidate 
> cycle you will need to wait to push until the next merge window.
Ok, no problem. Just let me know.
So far the changes are only in tdebase. I noticed you pushed a couple of commits for tdebase last night, so I could probably push my changes as well since a rebuild will be necessary anyway. Is it ok?

Security & Privacy changes are also ready and not pushed. Next up is Sound & Multimedia.

So far the changes are in tdebase and tdeutils.

Patches already available have been pushed for RC2.

Sound & Multimedia also updated and pushed.
Next System Administration, but first I need to make a full rebuild over the weekend.

System Administration completed. Next TDE Components.

TDE Components completed. Next a global review. If I don't find any more issues, I will close the bug.

Can we close this bug?

Thanks!

> Can we close this bug?
Not yet.
Although most of the work has probably been done, I have been reviewing some of the sections I hadn't worked on and found minor changes/improvements to be done. I haven't complete the review yet. As soon as everything is done I will close the bug.

Finally resolved!

It seems the help for multitab modules does not work any more correctly. To reproduce:
1) open TDE Control Center and choose a multi tab module (for example Regional & Accessibility -> Accessibility)
2) click the help button: khelpcenter opens the correct page but not at the correct section.
3) choose another tab from the same page and click the help button: again khelpcenter opens the correct page but not at the correct section (nothing seems to happen, but actually does happen behind the scene)
4) click again the help button on the same tab: this time khelpcenter moves to the correct section.

In summary: clicking one time opens the correct page but not the correct section. Clicking twice moves to the correct section.
The problem happens regardless of the fix for bug 2320. It may have been introduced by the fix for bug 2188 but I haven't verified yet.
i will work on this in the next days.

The problem was reintroduced by commit 687b146 used to fix bug 2188. The problem with bug 2188 is actually in another part of code ( TDEHTMLPart::gotoAnchor() ), so commit 687b146 have been reverted: commit 900f593 (master) and commit 2d6b821 (r14.0.x)