Feature Requests

[Psyches]

Originally Posted by gmau

Mark,
Thanks for your offer. It's been a few years that I had anything to do with editing web sites. I think it's best for me to create a web site with the help file.

I did manage to get one going. It's at

gmau

Looking for corrections and additions.

Gordon

Gordon, did you know that the tips.html I was referring to actually gets installed with OpenCPN, so it's a local help file on your system? There is no website that OpenCPN goes to for help.

From a quick review I do think yours looks better than the old one. Unfortunately I can't just do a file comparison to see what changed from the old because everything has changed due to reformatting and web-siteish things.

To incorporate your work, someone would need to recast this back into a separable help file (remove the statistics, counters, javascript and other site-oriented things) for this to go back into the OpenCPN code.

Maybe we'll get an ok from Dave and probably a volunteer to do that work, but I dunno. Want to be that volunteer?

[gmau]

Originally Posted by Psyches

Gordon, did you know that the tips.html I was referring to actually gets installed with OpenCPN, so it's a local help file on your system? There is no website that OpenCPN goes to for help.?

I suspected the above. The original and my file are html files. The original had no graphics. I added the graphics to give new users a comfort level. What the new user sees in the help file he would see when using the program. My understanding of html files is they will run on any pc as long as all the parts (graphics) are on the stand alone pc. The graphics are referenced from the main file. PDF or word files can be used but that requires the user to have those programs.

Originally Posted by Psyches

From a quick review I do think yours looks better than the old one. Unfortunately I can't just do a file comparison to see what changed from the old because everything has changed due to reformatting and web-siteish things.?

I used the original file as a base for my file. My updated file follows the same flow as the original. What I did was add graphics and expanded (inserted more steps) to the original with what the user would see while using the program.

The original file had a section on how to create a route. I added graphics and the steps necessary to create routes. After the 'getting the gps to work', I added a section on how to use a route.

Originally Posted by Psyches

To incorporate your work, someone would need to recast this back into a separable help file (remove the statistics, counters, javascript and other site-oriented things) for this to go back into the OpenCPN code.?

This is the easy part! All one has to do is highlight the contents of my website and do a copy into Word or OpenOffice writer. Save the file as html. You may have to wait awhile before saving until all the graphics gets down loaded to your PC. Start Explorer and find the saved document. Double click to open the saved document. It should come up just as the original tips.html comes up. I just did the above. Can you try it?

Originally Posted by Psyches

Maybe we'll get an ok from Dave and probably a volunteer to do that work, but I dunno. Want to be that volunteer?

Sure I'll help or be in charge of the help file.

[Psyches]

Originally Posted by gmau

I suspected the above. The original and my file are html files. The original had no graphics. I added the graphics to give new users a comfort level. What the new user sees in the help file he would see when using the program. My understanding of html files is they will run on any pc as long as all the parts (graphics) are on the stand alone pc. The graphics are referenced from the main file. PDF or word files can be used but that requires the user to have those programs.

Right, added graphics is one of the key things the help needed. And your understanding is correct.

Originally Posted by gmau

This is the easy part! All one has to do is highlight the contents of my website and do a copy into Word or OpenOffice writer. Save the file as html. You may have to wait awhile before saving until all the graphics gets down loaded to your PC. Start Explorer and find the saved document. Double click to open the saved document. It should come up just as the original tips.html comes up. I just did the above. Can you try it?

Well, yes and no. It's easy, and it basically works, but the result isn't highly desirable. I avoid using Word or office tools to edit html for the general public. Frontpage is better because its target is general html, but there are other free tools out there also tailored for this. Office tool html generation certainly has its place, but it isn't great for this exact case. I did try it with Word, just to see. Did you look at the html result when you did it? Here's what I found:

The result lost all the original metadata; the original css is gone; the charset moved from utf-8 to windows-1252; the file size is over twice the original, most of that due to new Word formatting gunk scattered throughout. There are still hrefs to your website here and there, even though the images were downloaded and are available and also referenced locally from the page.

You could scan for and hand-remove the hrefs, but thinking ahead here's the bigger problem: Visually, it looks pretty close to original; it'd be nigh impossible to validate with the old tips.html though, because you'd have to eyeball every sentence, side-by-side. That may not be a problem this time, since the original needed much improvement. But every new release will want a new tips.html, and it'll be impossible to just review the new changes using this approach - someone will have to completely re-validate the entire help file, every time...so this approach doesn't fit into a development and release process very well.

This is just my opinion - I'd be fine if someone (like Dave) disagreed and said "no, it's fine, we'll take it like this". I personally wouldn't want to replace the tips.html with this basically better one, though, until these issues were addressed. And it won't be all that hard to address them using another tool.

Originally Posted by gmau

Sure I'll help or be in charge of the help file.

Great! Want to check out another tool?

[dacust]

Originally Posted by gmau

Sure I'll help or be in charge of the help file.

HOORAY! Another sucker, umm, that is, another valued volunteer!!!

Seriously, it's great to have someone to help out on this.

-dan

[gmau]

Originally Posted by Psyches

The result lost all the original metadata; the original css is gone; the charset moved from utf-8 to windows-1252; the file size is over twice the original, most of that due to new Word formatting gunk scattered throughout. There are still hrefs to your website here and there, even though the images were downloaded and are available and also referenced locally from the page.

You could scan for and hand-remove the hrefs, but thinking ahead here's the bigger problem: Visually, it looks pretty close to original; it'd be nigh impossible to validate with the old tips.html though, because you'd have to eyeball every sentence, side-by-side. That may not be a problem this time, since the original needed much improvement. But every new release will want a new tips.html, and it'll be impossible to just review the new changes using this approach - someone will have to completely re-validate the entire help file, every time...so this approach doesn't fit into a development and release process very well.

This is just my opinion - I'd be fine if someone (like Dave) disagreed and said "no, it's fine, we'll take it like this". I personally wouldn't want to replace the tips.html with this basically better one, though, until these issues were addressed. And it won't be all that hard to address them using another tool.?

I checked the file sizes and got the following:

Original tips.html = 89 KB
OpenOffice Write HTML = 60 KB Plus jpg files
Word Doc = 30 kb

Copied from the web site to word and saved as a HTML file = 90 KB

About equal to the original.

I don't see any major changes added to the help file unless OpenCPN really changes. Line outs, colors, underscores, italicize for corrections and additions could be used. After everyone aproves they could be taken out.

Originally Posted by Psyches

Great! Want to check out another tool?

Sure I'm willing to try anything once or even twice.

Gordon

[Psyches]

Originally Posted by gmau

I checked the file sizes and got the following:

Original tips.html = 89 KB
OpenOffice Write HTML = 60 KB Plus jpg files
Word Doc = 30 kb

Copied from the web site to word and saved as a HTML file = 90 KB

About equal to the original.

I don't see any major changes added to the help file unless OpenCPN really changes. Line outs, colors, underscores, italicize for corrections and additions could be used. After everyone aproves they could be taken out.

Gordon, it sounds like you're getting better results than me then. I have Word 2003, and it's possible newer versions have fixed this. It's also possible the OpenOffice approach would be ok - I have no experience with that suite. So at least, we know the version of Word is important...don't want to use mine!

If you want to attach one or more of your html results, I'd be interested to look inside. Also if you're up for it, the help file you have is for OpenCPN 1.3.4, and as of yesterday there's a new beta 1.3.5 with cool new features that could use doc - notably the new grib UI. There's a new beta thread in this forum with the full release notes, if you haven't seen it.

Thanks for all your help!

Mark

[gmau]

Could some one give me a explanation of a grib file? I don't have a clue of what it is and what it does.

I've been thinking of starting a Help File thread.

Gordon

[idpnd]

Originally Posted by gmau

Could some one give me a explanation of a grib file? I don't have a clue of what it is and what it does.

I've been thinking of starting a Help File thread.

Gordon

Google/wikipedia are your friends..

[dacust]

I hate to say this, but I think we need another click-box in Tools. Auto-zoom when changing charts?

In another thread, someone was remarking that when switching charts, they wanted it to zoom to a readable zoom level.

Actually, I WANT it to be the same zoom. I like changing the scale of the chart and having the exact same area showing on the screen. It gives keeps me oriented. So, then I just scroll-wheel zoom out so I can see the chart. But while zooming out, my brain is adjusting to what I'm looking at.

As far as that goes, I wish the zoom-out was not restricted as well. When changing to a larger scale chart, I'd rather it didn't zoom in automatically, for the same reasons as above.

In other words, I'd rather totally control the zoom myself.

Interestingly, the ENCs have the same behavior, but you can zoom so much farther out on those (I wonder why?), that I never really get bothered by the auto-zoom-in.

-dan

[dacust]

For the Switzerland ENC chart, it includes some .jpgs of the bridge profiles.

I wonder if they are referenced from the chart in some way where a right click could allow them to be displayed?

Here is the chart and a coupla jpgs that can be downloaded, along with a directory listing of all the files.



-dan

[Totobeloeil]

I think OpenCPN menus could be automatically translated into the system default language (after someone made the translation file). I guess system default language is most of the time the same as the user's mother-language.

I made a coding to test this internationalisation / localisation feature upon opencpn1.3.4 (with po-edit and wxwidgets 2.8.10) on a Vista32 platform.

The idea is to do something very simple and, as far as possible, automatic (no modification to do inside the code when a new translation is made).

This could take place on the beginning of MyApp::OnInit() into chart1.cpp :

#include <wx/intl.h>

wxLocale    *def_lang;
wxString    loc_lang_canonical;
wxString    loc_lang_filename;

// Add a new prefix for search order. New prefix = .\lang, 
// where '.' refers to the opencpn.exe directory
      wxLocale::AddCatalogLookupPathPrefix(wxT(".\\lang"));

// Set default language
// i.e. : Set programer's language as default language
// because of trouble encoutered with wxLANGUAGE_DEFAULT
// and wxLANGUAGE_FRENCH
//        def_lang = new wxLocale( wxLANGUAGE_DEFAULT, wxLOCALE_CONV_ENCODING );
def_lang = new wxLocale( wxLANGUAGE_ENGLISH_US, wxLOCALE_CONV_ENCODING );

// Set filename without extension (exemple : opencpn_fr_FR)
// i.e. : Set-up the filename needed for translation
//        sprintf(loc_lang_filename, "opencpn_%s", def_lang->GetCanonicalName());
loc_lang_canonical = wxLocale::GetLanguageInfo(wxLANGUAGE_DEFAULT)->CanonicalName;
loc_lang_filename = "opencpn_" + loc_lang_canonical;

// Get translation file (exemple : opencpn_fr_FR.mo)
// No problem if the file doesn't exist 
// as this case is handled by wxWidgets
      def_lang->AddCatalog(wxT(loc_lang_filename));

Tested on Vista32 platform only. Result OK.

I did not think about a solution to translate the tips.html page.

Jean-Pascal

[idpnd]

Originally Posted by dacust

For the Switzerland ENC chart, it includes some .jpgs of the bridge profiles.

I wonder if they are referenced from the chart in some way where a right click could allow them to be displayed?

I think a number of the proprietary chart sets (bluecharts etc) have such a feature with marina photos and so on, probably highly useful when approaching an unknown port at night. These can often be found online.

Perhaps this could find its way into a possible XML layer?

[dacust]

Originally Posted by idpnd

I think a number of the proprietary chart sets (bluecharts etc) have such a feature with marina photos and so on, probably highly useful when approaching an unknown port at night. These can often be found online.

Perhaps this could find its way into a possible XML layer?

Yep. But that's actually a different feature than I was wondering about.

I was wondering if the ENCs from Switzerland already had an object type in it that refers to those jpgs since they include them in the ENC directory.

[Rhoel_Asia]

Just catching up on this thread:

Re the Web Code and updating the original help data in css - this has already been done for 1.3.4: It was to have been included with that release but was missed. Before 1.3.5 was released I hit a busy patch at work and failed to get it ready for Bob to include. What I did was to remove all the Word type style references in the data and replace with proper CSS. I then updated the icons and added additional screen shots of 1.3.4. I skipped including Javascript though there is no reason not to add a new JavaScript sub-folder with sharable functions. By using a common CSS and directory layout, it should be possible for many of us to contributor to the central help file.

I am happy to upload this to a common server for people to inspect, edit or whatever.


XML: Ippnd, the Google KML format is in fact standard XML format with predefined names and order. It can do what you are suggesting/requesting. Dave is looking at how KML can be included as layer information. I recently needed a degree shapefie grid for a project, so autogenerated the data in a KML file then used industry tools to convert to a shapefile. I tested it both Google Earth and against known data and it worked fine. Probably about 2 hours work to write all the for {} loops which generated the longitude/latitude lines, and for the conversion itself. So its relatively easy to work with KML generation - Google has a fabulous code support section for KML and it covers everything in great detail, including the whys than therefore of why its coded that way. Be great if all Open Souce had documentation like that.


Future Requests:

1: Go to function: it would very useful to have an input facility where yu could enter coordinated from the keyboard and a marker be placed at that location: Much of the code is already contained in the Move Boat to here function. I can see it being used when approaching a harbour, VTS/Clearance instructs you to go to peir 7 and its not on your chart. The give that to me in L/L" would enable you to find it fast and waypoint/reverse route.

2: Antipodal points: If you can do (1), then adding the anti-podal points is very easy, a N/S E/W inversion. Its more of a toy but still interesting for route planning - this was spurred by following Jessica Watson who mentioned she had rounded one of her anti-podal points. Struck me it could be useful to know this information.

3: LUA scripting: In a past life, I worked in the animation industry - there we used Lua and Python to script new features and generate data for use in the computer animation programs.

Knowing how useful that features was, I ask how difficult it is for a scripting module to be included in OpenCPN. If is it practical to implement, then it might provide a gateway for others to extend the functionability of OpenCPN by permitting people to write little-used functions (like calculating the anti-podal points) which are valuable but a waste of Dave's valuable time on his mainstream coding.

My understanding is the LUA script language is suitable for C/C++ and is cross Its also objected and able to address the C routines directly.


Rhoel

[cagney]

Originally Posted by dacust

Yep. But that's actually a different feature than I was wondering about.

I was wondering if the ENCs from Switzerland already had an object type in it that refers to those jpgs since they include them in the ENC directory.

Dan, they are referenced in the ENC file. For example the picture 4CMRBRK1.JPG is referenced on line 1803 in the ENC file 4C5RH149.000. It is up to the charting program to implement this feature.
Interestingly, according to this S-57 Encoding Bulletin, .tif is the standard picture format to use.

Thomas