use new QgsHelp where possible instead of builtin context help #4023
Conversation
| @@ -134,7 +134,7 @@ class QgsOracleSourceSelect : public QDialog, private Ui::QgsDbSourceSelectBase | |||
| //!Sets a new regular expression to the model | |||
| void setSearchExpression( const QString& regexp ); | |||
|
|
|||
| void on_buttonBox_helpRequested() { QgsContextHelp::run( metaObject()->className() ); } | |||
| void on_buttonBox_helpRequested() { QgsHelp::openHelp( QStringLiteral( "working_with_vector/supported_data.html#id2" ) ); } | |||
There was a problem hiding this comment.
To be honest, I still do not understand the way things are supposed to be implemented (sorry!). Will build this branch tonight :)
About the link, yes we should use more verbose link, because, if a new section or new hyperlink is inserted above in this chapter, the #id2 could not point to the same section
There was a problem hiding this comment.
Completely agree, it would be nice to have more verbose anchors.
There was a problem hiding this comment.
When the help button is clicked, the browser will be opened with the url http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/supported_data.html#id2
But you can also download and unpack the docs to e.g. /usr/share/doc/qgis/user_manual and configure this as an additional prefix with higher priority to have a local (preferred) doc.
@alexbruy correct me if I'm wrong please.
There was a problem hiding this comment.
Ok this is what I understood. But what changes does this require from the way we currently write docs? What should I be careful to not change the next time I update the doc (note that this chapter particularly is supposed to be reorganized in the future - qgis/QGIS-Documentation#1088)?
When the help button is clicked, the browser will be opened with the url http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/supported_data.html#id2
shouldn't it rather be this one http://docs.qgis.org/2.14/en/docs/user_manual/working_with_vector/supported_data.html#oracle-spatial-layers (the permanent link and not the relative one - which is btw #id25 and not #id2)?
There was a problem hiding this comment.
I think the main question to the doc is how to maintain a stable URI-schema (which is basically to be treated as an API).
- Either the current addresses will remain stable.
- Or there needs to be a mapping of stable addresses to resources (redirect mapping on the server)
What would be also nice is a travis check for dead links. Maybe have somewhere a list online (generated from QGIS master builds) with links which are in use. And join a second list generated from doc master builds. Where there is no matching doc, show it in red.
It's quite hard to get this right because doc and code are moving targets and there might be pull requests and stable releases involved.
There was a problem hiding this comment.
as @m-kuhn already said, this does not affect way we use to write docs. If you change something in the documentation, e.g. anchor name or move some section to another place you will need to update corresponding link in the code too. But I agree with Matthias here, that such changes should not be too frequent, at least within single version like 3.x, 4.x and so on
|
Nice @alexbruy , thanks for pushing this topic!! |
|
Thanks @alexbruy for your work |
|
I may be late in the organisation (if so, sorry! but it's also because I am not familiar with the vocabulary you used when creating the infrastructure) but is that intended to have a single file listing openhelp button and corresponding link/page? A kind of mapping between help buttons and doc section so that we have a single place to change links if ever? |
|
For flexibility I would do a mapping (if there is one) on the server and not in the app. |
|
Manually merged |
No description provided.