OpenCPN Beta Version 3.3.2410 Released

[bdbcat]

Chris....

Ummm....

I don't see a space in the latitude. The font is not helpful here, but I think the 5140.xxx has no space.

But I may be wrong.

Can you try another waypoint, say 4880.xxxx?
And confirm your log output as well?

Thanks
Dave

[Littlechay]

Originally Posted by nohal

Chris...
Can you check in the logfile as Dave suggests? To me it does not seem like there is a space between 51 and 40 at all.
How does the dual speed work? It really outputs at different speed over one wire and expects different one over the other at the same time? That is really weird...

Pavel

I'll check the log file tomorrow but I think there is definitely a space and not just the kerning. Either way it doesn't work but does from GPS utility.

The dual speed is not asymmetric. The GPS normally interfaces nmea at 4800 but when you put it into up/down load to PC mode it stops the normal nmea stream and switches to 38400 .

Chris


Sent from my iPhone using Cruisers Sailing Forum

[NahanniV]

Originally Posted by Littlechay

No I don't think so. Track implies historical data so track up would mean that you are retracing your track.... course is where you are going, track is where you have been.

Chris

I was thinking of Cross track error, but you are right.

BOD - Bearing - Origin to Destination.

or even Bearing Present Position to destination.

Could work.

Cheers,
JM.

[Hakan]

Originally Posted by bdbcat

Håkan ...

Lets be sure we understand what is theoretically possible.................
We should do something, though, because it is just not right for a PlugIn to be able to disturb an existing validated translation in the core. Not all PlugIns will play nice here.
Dave

Dave..
First.
In your previous post the 1, 2, 3 tasks are correct, I think it's exactly what's happen.
But it seems to be a to serious job to code a logic for this. But I agree that a plugin should not interfere to OCPN coding. And if Crowdin can't help to indicate a ambiguity we all has to solve it manually since poedit(?) can't handle two translations for the same word.

In my examples the word "Range" in src/AISTargetListDialog.cpp:412 and src/AIS_Target_Data.cpp:605 could be changed to "Distance", or we change in BR24radar. Someone to decide, please.

Thanks
Håkan

[seandepagnier]

Originally Posted by Gilletarom

hello Littelechay, Hello RGleason, Hello Dave :



@Littlechay :
I do not understand and / or I do not agree with you

We have a mode "Course up" ie a mode "COG up". To have a mode "Heading up" would require, on all ships, compass heading into the NMEA network.

There are many possible references to use for automatic rotational display:

1. Course from gps
2. Heading from compass
3. Heading from gps corrected for magnetic declination
4. Wind direction from anenometer
5. Wind direction from grib
6. Direction of next waypoint

Originally Posted by Littlechay

Your right, my explanation is bad.

Heading, and COG, vary as the boat yaws (depending on the systems damping) causing the screen to rotate.
...

This is gives a much more stable display, and is particularly useful when bashing upwind in short steep seas which constantly throw your bow off.

Chris

I propose we allow the above options, as well as changing the program so that instead of updating the angle every 10 seconds or so, it is just continuous and low-passed. This would greatly reduce jitter making the display smooth even in cases of low speed using gps course.

Originally Posted by bdbcat

Gilletarom...

Thinking more about PLugIn translation overrides...

It may be possible to create a method where PlugIn translations do not replace an existing core translation, if it matches exactly.

Would this resolve your difficulties?

Thanks
Dave

So.. if a plugin has a different translation for the same word, shouldn't that one be used in the plugin, and the translation with the main program used by that program?

I don't see why we couldn't at least override the _ macro to allow for this.

Originally Posted by Ptizef

Dave

Don't work for me too (French keyboard)
Jean Pierre

The only way is someone with a french keyboard must set a breakpoint and then press the appropriate key and find the key_code, if indeed you want this feature. This is what already happened for all the other keycodes, but the []\ ones are new and I have no french keyboard.

[RhythmDoctor]

As far as menu wording (in English), I think "North Up" and "Course Up" is about as clear as it gets - two words that provide a very good description of what the program is doing. I suggest that you leave it as-is in the English version.

As for the chart rotation being jittery in lumpy seas, I really think that this should be controlled by time-averaging over a period of seconds, set either by the "Course-up update period" or preferably "Filter NMEA Course and Speed Data." I am surprised that the program apparently does not do this already (or maybe those complaining have not tried adjusting this setting).

[bdbcat]

Ptizef...

On the black screen in overzoom....

Once more we see the weakness of Intel OpenGL drivers.
They do not support "Non-power-of-two textures."
I had not tested this on a true native intel-graphics Windows build until today. Clear failure, although on mine I got white screen instead of black.

Workaround will soon be in place for this in github.

Thanks for your patience
Dave

[Ptizef]

Originally Posted by boat_alexandra

The only way is someone with a french keyboard must set a breakpoint and then press the appropriate key and find the key_code, if indeed you want this feature. This is what already happened for all the other keycodes, but the []\ ones are new and I have no french keyboard.

Sean
The rotation code eliminate AZERTY keyboards by the test:
"if( !g_b_assume_azerty" chancv.cpp:1996
Without this test it works fine with alt gr [ , alt gr ] and alt gr \

Jean Pierre

[rgleason]

If "Rotated Chart" this is a legitimate and useful feature, and now I agree with Sean about this, (it could be a non-jumpy manually rotated version of "course up" too) I think we should support it in such a way that users know about it and can control it, across keyboards rather than hiding it or eliminating it on certain types of keyboards.

Perhaps we should look at a different set of keys that stays the same on the majority of keyboards? My laptop does have <>/ as Sean suggested, however I noticed that my Samsung touchpad keyboard does not have those keys...nor the []\. We couldn't we use () / or ' " / or R Shift-R /?
Keyboard Shortcuts | Official OpenCPN Homepage
Note: just added Alt for Menu bar toggle. May not be in right place.

Then there if the Options > User Interface > Show Compass Status Window is checked an icon could show with the Angle number (angle rotated +/-) from north up inside a simple ring with arrowheads both ways.

---All of this for a later time, of course (not COG).

[Ptizef]

If "Rotated Chart" this is a legitimate and useful feature, and now I agree with Sean about this"
Yes it could be and I agree to choose keys that suit to every device (if possible)

-just a remark : when smooth panning/zooming is off, the rotation is 10° for each touch on "[" or "]" .
It should be the same when on. I don't see any reason to make a difference

-another thought : I don't have a tablet abble tu run O and don't know how it reacts when you rotate it. Does the view rotates too? If it isn't the case, this functionality could help with a step rotation of 90°

Jean Pierre

[RhythmDoctor]

Originally Posted by Ptizef

-another thought : I don't have a tablet abble tu run O and don't know how it reacts when you rotate it. Does the view rotates too? If it isn't the case, this functionality could help with a step rotation of 90°

My Windows 8 tablet has an orientation sensor, and automatically rotates the entire Windows desktop (and running programs) 90°, 180°, or 270°. So the manual rotation is not needed for this.

Come to think of it, there are some issues with positioning of windows when the table rotates between landscape and portrait orientation. Specifically, the Dashboard plugin can move completely off the screen. As a result, I usually have to put it in the upper left corner of the OpenCPN window to make it friendly to portrait and landscape orientation. But it might be useful to build in some awareness of the changing orientation to keep the supplemental windows on the screen at different orientations.

[seandepagnier]

Originally Posted by Ptizef

If "Rotated Chart" this is a legitimate and useful feature, and now I agree with Sean about this"
Yes it could be and I agree to choose keys that suit to every device (if possible)

-just a remark : when smooth panning/zooming is off, the rotation is 10° for each touch on "[" or "]" .
It should be the same when on. I don't see any reason to make a difference

Jean Pierre

It is the same as panning and zooming. In smooth panning/zooming, there is rotation while the key is held down and it stops when released.

[Ptizef]

Originally Posted by bdbcat

On the black screen in overzoom...

Workaround will soon be in place for this in github.

Dave
May be it's too early, but I tried your last commit about blurring
Not fixed
I still get black over zoom, but it's a little more complex:
In shot1 attached, centered around 48°02.2840N - 04°50.90W
I can go to full zoom, but the last step shows a grayed view (as when dimming) and no blurring
In shot2 centered around 48°02.44N -04°45.59W, I get a grayed view then I can go to full zoom but still no blurring
In many others places I get a grayed view in the 2 or three last zoom step then the black view
Jean Pierre

[Ptizef]

Dave

1) full zoom /blurring works perfectly on the same machine with Ubuntu 14.04 in dual boot

1) Compiling with Ubuntu / Code::Block I get this warning:
||=== Build: all in OpenCPN (compiler: GNU GCC Compiler) ===|
/home/jeanpierre/Documents/OpenCPN/src/s52plib.cpp||In member function ‘void s52plib::GenerateStateHash()’:|
/home/jeanpierre/Documents/OpenCPN/src/s52plib.cpp|421|warning: comparison between signed and unsigned integer expressions [-Wsign-compare]|
||=== Build finished: 0 error(s), 1 warning(s) (5 minute(s), 3 second(s)) ===|

Jean Pierre

[bdbcat]

jp...

We are still dealing with oddities related to the OpenGL intel drivers for Windows. They are not very well implemented.

I'll try again.

Dave