View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001658||SkyChart||1-Software||public||17-02-23 10:45||17-02-25 16:26|
|Reporter||Sasa||Assigned To||Patrick Chevalley|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||3.11 SVN|
|Target Version||4.0||Fixed in Version||3.11 SVN|
|Summary||0001658: PDF Help download rate|
|Description||I have impression (sorry, I have no source here) that PDF help is always downloaded from http://www.ap-i.net/pub/skychart/doc/doc_en.pdf. I'm using it quite often.|
Is it possible to reduce the rate and download it only when actually updated (opening already downloaded local copy)?
|Tags||No tags attached.|
Yes this menu just call xdg-open with the URL for the PDF document, this normally result of the file to be downloaded by your default browser.
I put this link to the same section of the help menu as the other online resources because I think everyone can download and copy the file with it's other astro documents.
But I agree it is convenient to open the file from this menu and it may be interesting to change the way it work.
What is easy to do is to download the file to ~/.skychart/tmp if it is not already present, then every click to this menu just open the local file.
But the problem is how to manage the update?
As solution can be to add the version number to the file name.
This is easy for stable version but I also need a way for the beta.
Maybe add the same kind of sub-version name I already use to show the release notes?
Any other idea?
This perhaps may be easy solved with some text file ( or perhaps better .ini ?) on your server you may manage whenever upload new PDF help.
Stable: 2014-03-29 00:00:00
Beta : 2017-02-23 18:56:21
1. If there is no internet connection, it will be open local copy from HDD (user shared dir)
2. Whenever user click on "PDF Help", app will try to download the PDFHelp_Update.txt file from your server and compare datetime with existed stored locally. If PDF file not exists locally or datetime is changed it will download proper PDF (for stable/unstable release) and save locally (~/.skychart or ~/.skychart/tmp ) as well as PDFHelp_Update.txt and overwrite old ones.
3. Open locally stored PDF file.
I believe app can distinguish itself is stable or unstable release in order to download proper PDF file.
Then this is perhaps the easiest basic approach and user may have stable and unstable release with proper PDF as well allow update PDF for stable release.
Especially since I already have such a file for the menu Update/Search software update.
For the stable version this is http://www.ap-i.net/pub/skychart/version.txt
and for the beta http://www.ap-i.net/pub/skychart/beta.txt
I can add more rows and also get it on other occasion as you describe.
We also have locally stored HTML help files, we have to take care about. They also require update and as well differs for stable and unstable release.
This is a bit complicated if we now have to download specific updated files. Or similar as upper, easier to download entire zipped version (created on any HTML or bin file change) and unzip it locally.
This perhaps could be unify a bit. For instance:
[Purpose] [Datetime] [Other text / URL] [LocallyStored]
AppVer 2014-03-29 00:00:00 3.10-2854
PDFHelp 2014-03-29 00:00:00 http:\...\doc_en.pdf LocalPath\doc_en.pdf
HTMLHelp 2017-02-23 20:00:00 http:\...\HTMLHelp.zip LocalPath\HTMLHelp.zip
Or .ini version or similar. I usually use tab as separator in upper case.
The purpose will indicate what to do with rest of the line content and what action after download.
The stable and beta release version of files can be locally stored in different dirs or with different names.
Or whatever you find suitable.
It is probably better to not update the stable version documentation after the release.
If you look at the wiki right now with all the change concerning only 3.11/4.0 it make no sens to send this update to user of 3.10. And I not want to maintain branches for doc update.
So for stable version the problem is simple, download and use doc_4-0-en.pdf
For beta version the last html documentation is always included in the packages.
This only require to add a reference to doc_4-1-3756-en.pdf in beta.txt
There is no need for separate directory as you cannot have stable and beta version at the same time. (you can but it is your responsibility to script that correctly)
Thank you. It is all upon you to do what you find is suitable. I simply do not want to download thing I already have.
And I would like to see new stable releases on each 6 month or even less (with some important new feature). For these 3 years you did quite a few changes make release form 2014 obsolete many times now. As well new and updated catalogs in latest beta is something worth to forgot official "stable" release long time ago.
And more important, this last beta may consider to be much more stable that that from 2014.
This is implemented in rev 3544:
Version 4.0 will be released after I get one full week without a bug report I want to correct for 4.0.
|17-02-23 10:45||Sasa||New Issue|
|17-02-23 18:56||Patrick Chevalley||Assigned To||=> Patrick Chevalley|
|17-02-23 18:56||Patrick Chevalley||Status||new => assigned|
|17-02-23 18:56||Patrick Chevalley||Target Version||=> 4.0|
|17-02-23 18:56||Patrick Chevalley||Note Added: 0003646|
|17-02-23 19:59||Sasa||Note Added: 0003647|
|17-02-23 20:38||Patrick Chevalley||Note Added: 0003648|
|17-02-24 09:10||Sasa||Note Added: 0003649|
|17-02-24 09:13||Sasa||Note Edited: 0003649||View Revisions|
|17-02-24 10:03||Patrick Chevalley||Note Added: 0003651|
|17-02-24 10:05||Patrick Chevalley||Note Edited: 0003651||View Revisions|
|17-02-24 10:20||Sasa||Note Added: 0003652|
|17-02-24 10:21||Sasa||Note Edited: 0003652||View Revisions|
|17-02-25 16:26||Patrick Chevalley||Status||assigned => resolved|
|17-02-25 16:26||Patrick Chevalley||Resolution||open => fixed|
|17-02-25 16:26||Patrick Chevalley||Fixed in Version||=> 3.11 SVN|
|17-02-25 16:26||Patrick Chevalley||Note Added: 0003655|