Imagine you install scidavis-0.2.2 with manual in /usr/share/doc/scidavis-0.2.2 and using manual.path = $$INSTALLBASE/share/doc/scidavis-manual-0.2.2
you use scidavis and this help path is written in .config/SciDAVis/SciDAVis.conf
now you update scidavis to 0.2.3 with manual in /usr/share/doc/scidavis-0.2.3 and using manual.path = $$INSTALLBASE/share/doc/scidavis-manual-0.2.3
you launch scidavis and the help files was not found because the help path written in .config/SciDAVis/SciDAVis.conf is still /usr/share/doc/scidavis-0.2.2
It's a problem because you need to delete .config/SciDAVis/ to make it work!
Is there a solution ?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Still, having to change the manual path after every update seems a bit less than ideal. The problem seems to be that on the one hand, there are packages of the manual which have to follow a distribution's policy for where to put documentation (/usr/share/doc/scidavis-<version> in this case). For these, it would be better to default to the compiled-in path. On the other hand, we have users unpacking the manual somewhere (e.g., in their home directory), for whom the current behaviour of maintaining the manual path as a configuration setting is correct.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good idea. I've added a compile-time switch, so that (starting with the next release) packagers can decide which strategy is most apropriate for their users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think there's a way to extract a patch for more than one file from the web interface. Using the command-line svn client, you can extract the patch using
Thanks a lot! I'm not sure to well understand the use of DEFINES += DYNAMIC_MANUAL_PATH. Either you add this line and the path used is stored in config file or you comment this line and the path used is always the one defined in manual.path ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you add this line, the path from the configuration file is used - just like without the patch. With the line commented out, the configuration setting is ignored and the manual is always searched for in the path chosen at compile time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks it works fine now. Another good thing would be to disable at compile time the functions to download manual, Translations and new version available as it's not usefull for official packages. What do you think ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure that these cannot be useful for users of official packages, but I do see that one would want to encourage using the appropriate packages for installing/updating manual, translations and new versions. Anyway, I don't see a big issue with adding some more compile-time switches.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No it does not work! In fact to make it working you need to remove .assistant/contentdb40.scidavis_manual_en if you don't remove it each manual page show The page could not be found
'file:///usr/share/doc/scidavis-manual-0.2.2/x94.html'
whereas the page should be /usr/share/doc/scidavis-manual-0.2.3/x94.html
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure whether the configuration file for Qt Assistant (scidavis.adp) should/could contain a version property for tracking changes to the manual (such as a different path). There doesn't seem to be a good summary of the fileformat. In any case, it should be possible to add version information to the 'name' property; which would mean that Assistant should create a new content db (such as contentdb40.scidavis_manual_en_0.2.3).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure to understand where is the solution ...
I'm not a Qt guru but i think this problem is quiete current, no ?
Adding the version information to the name property by patching scidavis.adp will fullfill the .assistant directory without any reason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Imagine you install scidavis-0.2.2 with manual in /usr/share/doc/scidavis-0.2.2 and using manual.path = $$INSTALLBASE/share/doc/scidavis-manual-0.2.2
you use scidavis and this help path is written in .config/SciDAVis/SciDAVis.conf
now you update scidavis to 0.2.3 with manual in /usr/share/doc/scidavis-0.2.3 and using manual.path = $$INSTALLBASE/share/doc/scidavis-manual-0.2.3
you launch scidavis and the help files was not found because the help path written in .config/SciDAVis/SciDAVis.conf is still /usr/share/doc/scidavis-0.2.2
It's a problem because you need to delete .config/SciDAVis/ to make it work!
Is there a solution ?
Thanks
Yes. Use the menu item Help->Choose Help Folder.
Still, having to change the manual path after every update seems a bit less than ideal. The problem seems to be that on the one hand, there are packages of the manual which have to follow a distribution's policy for where to put documentation (/usr/share/doc/scidavis-<version> in this case). For these, it would be better to default to the compiled-in path. On the other hand, we have users unpacking the manual somewhere (e.g., in their home directory), for whom the current behaviour of maintaining the manual path as a configuration setting is correct.
Is it possible to disable Help->Choose Help Folder and only use system-wide compiled-in path so we can choose the better at the compilation time ?
Good idea. I've added a compile-time switch, so that (starting with the next release) packagers can decide which strategy is most apropriate for their users.
When do you plan the next release . Or can i use a patch to patch 0.2.3 version ?
Thanks
I'm tentatively planning to do the next release in a month or so.
However, you can always check out the current state of development using a Subversion client from
http://scidavis.svn.sourceforge.net/svnroot/scidavis/branches/current_stable
or using the web interface at
http://scidavis.svn.sourceforge.net/viewvc/scidavis/branches/current_stable/
I don't think there's a way to extract a patch for more than one file from the web interface. Using the command-line svn client, you can extract the patch using
svn diff -c 1181 http://scidavis.svn.sourceforge.net/svnroot/scidavis/branches/current_stable
Thanks a lot! I'm not sure to well understand the use of DEFINES += DYNAMIC_MANUAL_PATH. Either you add this line and the path used is stored in config file or you comment this line and the path used is always the one defined in manual.path ?
If you add this line, the path from the configuration file is used - just like without the patch. With the line commented out, the configuration setting is ignored and the manual is always searched for in the path chosen at compile time.
Thanks it works fine now. Another good thing would be to disable at compile time the functions to download manual, Translations and new version available as it's not usefull for official packages. What do you think ?
I'm not sure that these cannot be useful for users of official packages, but I do see that one would want to encourage using the appropriate packages for installing/updating manual, translations and new versions. Anyway, I don't see a big issue with adding some more compile-time switches.
No it does not work! In fact to make it working you need to remove .assistant/contentdb40.scidavis_manual_en if you don't remove it each manual page show The page could not be found
'file:///usr/share/doc/scidavis-manual-0.2.2/x94.html'
whereas the page should be /usr/share/doc/scidavis-manual-0.2.3/x94.html
I'm not sure whether the configuration file for Qt Assistant (scidavis.adp) should/could contain a version property for tracking changes to the manual (such as a different path). There doesn't seem to be a good summary of the fileformat. In any case, it should be possible to add version information to the 'name' property; which would mean that Assistant should create a new content db (such as contentdb40.scidavis_manual_en_0.2.3).
I'm not sure to understand where is the solution ...
I'm not a Qt guru but i think this problem is quiete current, no ?
Adding the version information to the name property by patching scidavis.adp will fullfill the .assistant directory without any reason
I think I've found a better solution. If you touch the file manual/scidavsi.adp, then Assistant will update the cache correctly.