Sean's Optimum Branch Merge

[muttnik]

Originally Posted by boat_alexandra

It was relatively straightforward (one define needed to be added to CMakeLists.txt to fix some obscure wcsstr string errors)

Any tips? I had a first stab at putting together a build environment to test my changes on 10.9 last night and ran into similar sounding errors. Might well be my 3.0.0 wx build (it was late, didn't look too closely...).

I'm relatively new to both Mac and wxWidgets.

[seandepagnier]

yes, was using wx 3.0.0, but I forget the flag we used. With any luck I can post tomorrow.

[seandepagnier]

Originally Posted by Baikal

3.3.1715 assembly problems with chart Quilting
OpenGL - ON

I suspect this is because of the OCPNRegion change. Which charts? What lat/lon?

[Baikal]

Originally Posted by boat_alexandra

I suspect this is because of the OCPNRegion change. Which charts? What lat/lon?

ENC S-57 ed3.1
Lake Baikal Russia

[seandepagnier]

Originally Posted by Baikal

ENC S-57 ed3.1
Lake Baikal Russia

I have the USA enc charts.. where can I download the russian ones?

[Baikal]

Originally Posted by boat_alexandra

I have the USA enc charts.. where can I download the russian ones?

Wrote PM

[cagney]

Originally Posted by bdbcat

The way a dashed line is drawn between light sectors, seems flawed.
sector-d.png
A dashed line is drawn for each bearing defining a sector. When there  are contiguous sectors this leads to a double dashed line, where one  sector ends and the next starts. This is clearly visible in the picture.  This was not present before the merge.

Fixed in github now.

Last call, Beta coming!

Thanks
Dave

Dave

I checked again with today’s git code.
It looks like this



compared to 3.3.1712, that looks like this



Still not quite right....

Thomas

[nohal]

Thomas...
Is your tree really up to date? I see it fixed.

Pavel

[cagney]

Originally Posted by nohal

Thomas...
Is your tree really up to date? I see it fixed.

Pavel

Pavel

Thanks. I checked again. The tree is all-right, but I probably had a stale bg instance running somehow. Accessing the binary directly instead of via a graphic shortcut set things right.
Sorry for the false alarm

Thomas

[ChuckSK]

Dave

The ChartSymbol texture is not loaded on start-up. The texture is available only after changing the color scheme.

Chuck

[ChuckSK]

Originally Posted by ChuckSK

Dave

The ChartSymbol texture is not loaded on start-up. The texture is available only after changing the color scheme.

Chuck

Your latest commit did not fix this problem. I have been testing this in the debugger.

[bdbcat]

Chuck...

Texture symbols should be OK now in github. Problem was in Windows OpenGL canvas sequencing, somewhat different than linux.

Thanks
Dave

[seandepagnier]

I noticed the following in chart1.cpp:

    //  French language locale is assumed to include the AZERTY keyboard                            
    //  This applies to either the system language, or to OpenCPN language selection                
    if( loc_lang_canonical == _T("fr_FR") ) g_b_assume_azerty = true;
    if( def_lang_canonical == _T("fr_FR") ) g_b_assume_azerty = true;

I think this explains a lot of problems reported by french users related to keys. Is it actually safe/correct to make this assumption? I think there must be times when french users have a qwerty keyboard.

[sailorF54]

Originally Posted by boat_alexandra

I noticed the following in chart1.cpp:

I think this explains a lot of problems reported by french users related to keys. Is it actually safe/correct to make this assumption? I think there must be times when french users have a qwerty keyboard.

- Any laptop bought in France will have an Azerty keyboard and a French version of Windows...
- Plug and play separate keyboards would also be Azerty.
- I have not the faintest idea what happens if you plug a qwerty keyboard
- You can map an Azerty keyboard to qwerty using the ' country or region settings > keyboard and language' (or a keyboard shortcut) that is have the a key "prints" q, but that's a nuisance...

- I mainly use French locale for O, although I often switch to US English when testing O in order to be able to take screenshots, but the keyboard is obviously still azerty.
- There must be a way to access some W parameter that tells which kind of keyboard is used

[bcn]

IMHO the program should not make any assumption about the keyboard used.

There are endless variants - or: there is nothing like a "standard keyboard".

We are having here Spanish, English and German kbd's at hand for example.