OpenCPN Version 2.1.0 Beta

[SethDart]

One more follow-up, now on i18n

1/ While working on cmake, I noticed previous makefile installed mo files under $(DESTDIR)$(datadir)/locale/de/LC_MESSAGES/opencpn_de_DE.mo (example for Germany, similar for each locale)
I didn't understood why "_de_DE" was left in the filename part, the path should be enough for gettext to find the appropriate language file for selected locale. This is how every other (GNU/Linux) software do.
Then I checked how Debian & RPM OpenCPN packages managed that, some were doing the same, other not. Well, confusing...

IMHO, the catalog should always be "opencpn": in src/chart1.cpp:1032

- wxString loc_lang_filename = _T("opencpn_") + loc_lang_canonical;
+ wxString loc_lang_filename = _T("opencpn");

With this change (and renaming .mo files properly) users may take advantage of the current "de_DE" localized OpenCPN with locale like "de_AT" or "de_CH"

2/ The next question (rethoric) is the path this .mo locale files should be installed. For now, we use $(DESTDIR)$(datadir)/locale/de/LC_MESSAGES
This is good for the German speaking users not living in Germany (hi gals&guys). It'll become harder if we get a "de_AT" localized file in the future.
One solution is to rename .po files in the tree, the installer will do the rest. Let me explain this:
- we rename po/opencpn_de_DE.po to po/de_DE.po
- the installer will take that file, build the .mo version and install it in (DESTDIR)$(datadir)/locale/de_DE/LC_MESSAGES/opencpn.mo
If we want it in locale/de/LC_MESSAGES simply rename the .po original file to "de.po". When we get de_AT.po simply push it in CVS and the installer will take care of it.

This change would ease installation process, locale management and benefit to users. There's only one slight change required in CMakeLists.txt Currently, everything is hardcoded in that file, if we choose that solution, it can be generic : no more change required after adding a locale.

3/ The 3 following functions are currently used in the code wxT(...) _T(...) _(...) for strings
Only the last one is used with xgettext to extract strings for translation (pot file). _T(...) seems to be used only for debug/error messages.
I found some missing translation because of the use of the 2 first instead of _(...) I'll send a patch to SF for these.
Should all strings be localized/localize-able? Am I right with the assumption of the use of _T() for debug/errors only? What about wxT(...)

Comments welcome
Thanks

[Ptizef]

Hi Dave

Many thanks for your answer .
As you suggested , I eliminated BSB 5722 and others , that solved the problems I described . Nevertheless I've still a problem unsolved , with a curious behavior :
Let looks at screen shot test01 . Starting at this position (the boat should be near screen center )
- With quilting enable for both cm93 and bsb , if I zoom + , I get immediately a crash
- with quilting enable for only bsb , if I zoom + , it's OK , but if I zoom - , I get sreen shot test02 AND opencpn closes itself (without crash) .
- with quilting enable for only cm93 , no problem
here the log file after opencpn exits itself :
8:51:52 PM: Opencpn language set to: en_US
8:51:52 PM: Using s57data in C:\Program Files\OpenCPN\s57data
8:51:52 PM: Using Tide/Current data from: C:\Program Files\OpenCPN\tcdata\
8:51:52 PM: Setting Viewpoint Lat/Lon 51.438, 4.1031
8:51:52 PM: Setting Ownship Lat/Lon 50.6816, 1.5989
8:51:52 PM: NMEA Data Source is....Serial:AIS Port (Shared)
8:51:52 PM: AIS Data Source is....None
8:51:52 PM: Using WVSChart datafile: C:\Program Files\OpenCPN\wvsdata\wvs43.dat
8:51:52 PM: NMEA AutoPilot Port is....None
8:51:52 PM: Loading chart db version: V016
8:51:52 PM: Chart directory C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3
8:51:52 PM: Chart directory C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009
8:51:52 PM: GPS Watchdog Timeout is: 6 sec.
8:51:53 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6608.kap
8:51:53 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6904_2.kap
8:51:53 PM: VP Final Check: Georeference Chart_Error_Factor on chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6904_2.kap is 0.0902715
8:51:55 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\7312.kap
8:51:58 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\7311.kap
8:52:00 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\2042_4.kap
8:52:01 PM: x_malloc...malloc fails with request of -2147483648 bytes.

as you can see , there is a chart with error , but I've already eliminated many and each time there is another . It seams that the more I eliminate charts with error , the more opencpn finds other error

here the log file after a crash as described
:56:20 PM: Loading chart db version: V016
8:56:20 PM: Chart directory C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3
8:56:20 PM: Chart directory C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009
8:56:20 PM: GPS Watchdog Timeout is: 6 sec.
8:56:20 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6608.kap
8:56:20 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6904_2.kap
8:56:20 PM: VP Final Check: Georeference Chart_Error_Factor on chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\6904_2.kap is 0.0902715
8:56:22 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\BSB3\7312.kap
8:56:26 PM: Found Garmin USB Driver.
8:56:30 PM: Initializing Chart C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\003000 00\A\00300000.A
8:56:30 PM: CM93Composite Chart Root is C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\
8:56:30 PM: Loaded CM93 Dictionary from C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\
8:56:30 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039010 20/A/03901020.A
8:56:30 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039000 00/A/03900000.A
8:56:33 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039010 20/B/04201050.B
8:56:34 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039000 00/B/04200000.B
8:56:34 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039009 60/Z/03900960.Z
8:56:34 PM: Loading CM93 cell C:\Users\Jean Pierre\Documents\Bateau\Cartes\CM93ed2_2009\039000 00/Z/03900000.Z

I hope I've been clear

regards
Jean Pierre

[cagney]

Dave
Testing Ptizef scenario using the same chart view. All french charts in the area loaded. Don't know if this is covered in your last post or not, anyhow....
Quilting with cm93 and raster hitting "+" in quilting mode the program hangs, and later, after restart, the program crashes on just hitting F9. First dump below is for the crash, but looked the same when hung.
Ptizef:s second picture, same experience. The opencpn process becomes a CPU and memory hog, screen is all gray for a long time. Hitting "-" repeatedly alternates between the black screen with charts outlined in red and showing a raster chart, with prolonged delays in between . The second dump taken on a prolonged "gray-out".
Thomas

[Totobeloeil]

Originally Posted by SethDart

One more follow-up, now on i18n
[...]Comments welcome

1/ 2/ It is only about naming conventions. This was done to clarify post-exchanges about i18n, do less mistakes and retrieve easily what mo-file is used at one time (not have to go inside the file to understand it was not the 'good' one).
Why is it so important to change this ? Where is the problem exactly ?

3/ I believe we only have to translate user-interface strings.
What missing translation did you find (for example) ?

Jean-Pascal

[Ptizef]

Hi Dave
Following my post and Cagney's one , I try to run opencpn in VC++ under debug (I'm not very skilled in that)
You can see in the shot attached (crash1) what I obtained when crash occurred using quilting enable for both cm93 and bsb and zoom+ (case one)
It seams the problem occurred in cm93.pp line 4503
When opencpn close itself after zoom- with only bsb (case two) I get almost nothing (shot exit1)

If that can help
regards
Jean Pierre

[raisin56]

Anybody having a problem with the ships bells in 415/416? mine stopped working I believe with 415. I went back to 331 and they work there. Windows build on XP box.
Also any insight into audio on the anchor watch, never had sound just a visual alert. Do I need to enable something in AIS as I don't use that feature.

Thanks
Dan

[SethDart]

Originally Posted by Totobeloeil

1/ 2/ It is only about naming conventions. This was done to clarify post-exchanges about i18n, do less mistakes and retrieve easily what mo-file is used at one time (not have to go inside the file to understand it was not the 'good' one).

Well, it's purely technical. I'm not talking about translation nor file exchange here. It's only about file management in CVS, installation of files and packaging. You can keep using your file naming convention for all the translation process. And I guess you've never "gone inside" a mo-file: it's binary! Maybe one day we'll use tools such as Transiflex to ease translators job.

Originally Posted by Totobeloeil

Why is it so important to change this ? Where is the problem exactly ?

Not that important. That's only my understanding of the problem. While working on Cmake, the only thing I'd to leave hardcoded was the installation of mo-files part. The solution I suggest here could avoid that. That's all. It'll ease future work, IMHO.

Originally Posted by Totobeloeil

3/ I believe we only have to translate user-interface strings.
What missing translation did you find (for example) ?

I sent a patch to SourceForge yesterday, you'll find everything there. It's mostly dialog titles, a few in AIS & GRIB and a few buttons.

[cagney]

Hamish

Simply making one bigger or smaller with a fudge factor just ain't gunna cut it. The two projections are fundamentally different and you can't plaster over that.

Look at the screen-dump below. I was throwing some ideas around to make the quilting with merc & tmerc better, not perfect. To me it is appears that the tmerc plan has a smaller scale than the surrounding chart. I can't see that this has anything to do with the fundamental differences between the projections, more likely it depends on code and rendering. Feel free to educate me if I'm wrong.

So in the end it is a question of the quality of this file.
the .hdr?

I was talking about the headerfile, or what the libbsb documentation calls template.kap that creates part of the text header in the final .kap file. If you have a quick look back at the start of the chart thread, you will find a lot of discussion about the correct syntax for this file. There was a lot of errors in this respect in the world-merc- chart. Of course the quality of the tiff image has a lot to do with the final quality of the chart. What can be done to a given picture in this area has not been discussed much, and I would welcome any hints in this area. Compared to most chart-pictures that I have come across the NZ tiff chart images has an outstanding quality.

So what exactly is the problem with libbsb?
Time for a bug fix perhaps?.

Dave.....what is your take on libbsb?

Thomas

[bdbcat]

Ptizef and Cagney....

Thanks for the debug traces regarding crashes/hangs on quilting.

Two things going on here:
1. cm93: a problem near longitude 0, easy fix. Moles again...
2. Lots of questionable charts in SHOM set. Nonsense PLY values, mostly.
Leads to very, very small chart bounding regions, less than 1 pixel in size, causing logic crash. Present chart in this case is 2042_4.kap
Are these charts usable in any other ECS?

Fixes:
1. New cm93.cpp in CVS now to fix Problem (1).
2. in chcanv.cpp: This source is not in a fit state to upload at the moment. Please simply comment out the following lines in your current source:

542:                if(chart_region.IsEmpty())              //Empty regions can come from bad chart files, e.g. SHOM 5722.kap
 543:                      chart_region = wxRegion(0, 0, vp.pix_width, vp.pix_height);

Checkout cm93.cpp, edit chcanv.cpp, recompile and all should be well for these problems.

Question then is: Should I try to detect these bad charts on database load and mark them as unusable , with log entries to suit? Or simply ignore them on the fly. Rhetorical question I guess.....

Thanks again
Dave

btw Ptizef: It is very useful to have a competent Windows VC++ debugger on the team. Good Job!

[Totobeloeil]

Originally Posted by SethDart

You can keep using your file naming convention for all the translation process.

Naming conventions are not mine. They are collective.

Originally Posted by SethDart

And I guess you've never "gone inside" a mo-file: it's binary!

It happens very often that some data are human-readable inside binary files. And it does for mo-file.

Jean-Pascal

[Ptizef]

Hi Dave

Thanks for your answer
I loaded the new cvs and built it , but I didn't understand what I have to do in chcanv.cpp ? There is already the two lines you mentioned . What do you mean by 'comment out' ( sorry for my poor English !) Do I have to deactivate its ?
In any case I tried both and the result was not clearly different : Somethings have changed : I have no longer the crash (case 1) , but :
- I get crashes systematically when zooming + , the cursor round position 49°42.5 N , 01°22.8W . oddly enough , the result in Vc++ debugger is not always the same (see shots crash1,crash2,crash3) May be I've done something wrong ?
- Zooming and moving are very-very low in this region - opencpn hangs for a few time before the crash .
- I have still some space where there is no chart displayed (Only outlines ) at particular scale (see shot emptyscreen1) whereas there are cm93 and several bsb available

For the bad charts , I think it would be better , if possible , to put it in a log when building chart base . This would allow users to know and eliminate its (or correct its if a tool exist ? )

best regards
Jean Pierre

[bdbcat]

Ptizef....

Sorry for my American jargon. I mean that you should de-activate lines 542-543 in chcanv.cpp, and re-compile.

I will study the lastest crashes tonight.

Thanks
Dave

[cagney]

Dave & Ptizef

The new code works.
After the patches I don't get crashes or "hungs". I'm not able to reproduce the latest crashes that Ptizef refers to, following his instructions. Some minor black persistent areas,but mostly when I get black patches the disappear if I for example zoom in and then go back to the same scale again.

Thomas

[sinbad7]

Thanks Dave..

The new version works fine for me with both AIS and all my previously converted .kap charts. Running Vista on my laptop

I shall continue testing and report back as required.

Great job!!!!

[SoggyPaws]

I am in lower French Polynesia (in the Gambiers group) and have been trying to download the newest beta build for Windows for a week. I can't seem to get a download to complete. We are on very slow/tenuous internet here.

Does anyone have it in a place where I can FTP it down and be able to resume broken downloads?

I would love to play with it (with Maxsea running side-by-side just in case!) while we're cruising French Polynesia.

Thanks,
Sherry
s/v Soggy Paws