Page MenuHomePhabricator

Configure F1 help on a per view basis
Closed, ResolvedPublic

Assigned To
None
Authored By
goch
Sep 11 2012, 5:31 PM
Referenced Files
Unknown Object (File)
Sep 11 2012, 6:26 PM
Subscribers

Description

After removing the bundlemainpage macro pressing F1 will lead to an index.html which will in turn link to related pages, which will link to the corresponding help page of the bundle.

While this could be fixed again by using the bundlemainpage macro I propose a different solution. The original solution has one index page for each bundle, which in extreme cases, like the diffusionimaging bundle, means that all 10+ views will link to the same help page.

Instead we could make it configurable on a per view basis which help file should be loaded, if F1 is pressed while the view is focussed, this will allow opening the exact file for that view, which is more in line with a quick help function.

This could be done by using a central reference file in a format similar to:
bundle.id "default page"
view1.id "view 1 page"
view3.id "view 3 page"
view4.id "default page section view 4"

Where any missing views are linked to the default page.

Another option would be to assign the information within the view header/source file.

Any comments?

Event Timeline

For a quick fix of the current behaviour of linking to a incorrect main page you can replace
QUrl pluginIndexUrl(loc.arg("index"));
by
QUrl pluginIndexUrl(loc.arg("pages"));
in the function
void HelpContextHandler::handleEvent(const ctkEvent &event)
of
berryHelpPluginActivator.cpp
then F1 will call up the "related pages" page of the doxygen documentation.

Couldn't we just use a naming convention for main View help pages such that they use a Doxygen identifier in the \page command which corresponds to the View id?

By pressing F1, we could then get the current View id and construct a suitable Url. Maybe I am missing something...

The only problem with that approach, that I can see, is that this would preclude constructing a bundle where:

View 1 and view 2 should share page 1 and view 3 and view 4 share page 2

That is true. Do we have such cases?

Currently, the code HelpContextHandler::handleEvent() tries to load a help page for the currently active view. If that page doesn't exist, it tries to open the "index.html" file of the plug-in contributing the view. With the recent removal on "bundlemainpage", I am not sure if this index.html file still exists.

The index.html still exists. It just has two links "MainPage" (which points to itself) and "related pages" (which points to the related pages).

I think currently we do not have any cases as described in Comment 4. I will look into whether sections names like the viewId can maybe be found.

See bug-13076-tweak-f1-behaviour-and-doxygen-identifiers

[bcc9ba]: Merge branch 'bug-13076-tweak-f1-behaviour-and-doxygen-identifiers'

Merged commits:

2012-09-12 19:01:05 Caspar Goch [f9cdc3]
Merge branch 'bug-13076-tweak-f1-behaviour-and-identifiers' into bug-13076-tweak-f1-behaviour-and-doxygen-identifiers

Conflicts:
BlueBerry/Bundles/org.blueberry.ui.qt.help/src/internal/berryHelpPluginActivator.cpp


2012-09-12 18:59:29 Caspar Goch [339d6a]
Adjust identifiers


2012-09-12 18:58:27 Caspar Goch [6ce213]
Look first for view id, then plugin id, then index.html


2012-09-12 18:55:15 Caspar Goch [0069bf]
Moved manual to correct bundle


2012-09-12 17:00:18 Caspar Goch [c2ddbe]
Look first for view id, then plugin id, then index.html