OpenCPN Beta Version 3.3.2316 Released

[rgleason]

Version 3.3.2316 Compile successful, result one warning {corrected]

Build succeeded.
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\plugins\dashboard_pi\dashboard_pi.vcxpro j" (default target) (8) ->
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.vcxproj" (default target) (10) ->
(ClCompile target) ->
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(632): warning C4005: 'M_PI' : macro redefinition [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.vcxproj]

1 Warning(s)
0 Error(s)

Thank you all for the improvements to Opencpn which I believe gets better with each release.

[RhythmDoctor]

Originally Posted by bdbcat

Gilletarom...

I am sorry you feel that O is becoming more complicated. That is not the intent.

The idea is that OCPN will "do the right thing", with very minimal input on the configuration screens, as initially installed.

And I think 3.3.x does that better than 3.2.x ever did.

Agreed, the options tabs are complex. But then so is electronic navigation in general. We intend to provide configuration options for a wide variety of installations and equipment, so we have a lot of options.

But virtually none of those complex options are required for initial use by novices. As has been said, get a GPS, get some charts, and go. O works fine with default settings.

About the fogging:
I feel pretty strongly about the dangers of overzoom. I cruise in the real world, full time 12 months/year, covering thousands of miles per year, in areas where the best charts are unvalidated cm93.

I personally observed a the results of wreck in the Bahamas where overzoomed charts were one proximal cause of the wreck.
http://www.cruisersforum.com/forums/...mas-98087.html

So I know it happens in the real world.

Simply, it would be remiss of us to show highly overzoomed vector charts with implied single pixel accuracy. The accuracy is just not there.

Also, please recognise that the implied accuracy on overzoom applies mainly to vector charts. Raster charts, when overzoomed, show the characteristic "blockiness" of pixels. I am sure we would agree that any navigator could see that a small scale raster is unreliable at overzoomed scales.


Lets take a specific example and analyse it with real numbers.

Using Håkan's example location. The cm93 cell shown in the attached image (ozx1) is at a native scale of 1/50,000.

Recall that virtually all vector charts come from tracing or digitizing original paper charts, and that the compilation scale of vector charts is seldom known precisely.

So, apply the rule of thumb that cartographic details are accurately charted to a position of one pencil width( 1mm) at twice the stipulated nominal scale.

This means that at a screen scale of 1/2400, the accuracy of geographic features on this particular chart at this particular screen scale is about 10mm. I hope that math is clear...

I have taken the liberty of manually editing the screen shot to blur the geographical features out to 10 mm at 1/2900 and attached as ozx2. This is a rough equivalent of what one might see on a raster chart of the same native scale, if one were available.

Would you navigate with this chart at this scale in a place you have never been before, or at night? I would not, and that is my essential argument.

By the way, how did I learn the native scale and get an un-fogged image to work with? Press F9, switching to single chart mode. Chart piano bar key rollover will show the chart scale, and OZ fogging is disabled for single chart mode.

Let us continue the discussion with real examples, and with native scales noted. That is the only way to make sense of this admittedly complex issue.

Thanks for listening
Dave

Dave,

I like the fogging feature. I agree that you need to be concerned with people overzooming the charts, especially with vector charts that don't exhibit the "lumpiness" of overzoomed raster charts.

I do not believe that OpenCPN has gotten too complicated. Yes, there are lots of settings that can be adjusted, but for the novice user the program provides good default settings to get them started. I still am disappointed that so many people are put off by the complication of having to download their own charts and set the chart directory. (That's the #1 complaint I hear from those who tried O and didn't like it.) It's specially surprising here in the US, where the charts are free and easily located online. But since a large number of potential users are barely savvy enough to do that, they would also fall into the same category as users who could overzoom charts and not realize what the obvious "Overzoom" warning actually means in terms of dangerous navigating. For those people, the fogging becomes a more effective, less subtle hint that maybe they shouldn't be zooming in so far.

And for the more savvy users who know the dangers of overzooming and want to see the detail anyway, they should be sophisticated enough to know how to turn off quilting (or edit the .ini file) and see the charts at full contrast.

All in all, I think that the fogging is a good safety feature.

[Hakan]

I love this!
Dave, I love your responsibility to not produce things that can possible cheat other people to a imprudence feeling of security. And I'm impressed of the way you express it, it's nice to read. I do also agree on the fogging method to express the uncertainty of the charts. Your info that a single chart mode is not fogged is the solution for me, thanks. Then it's no need for a config file setting.

The Swedish charts in this area are surprisingly accurate although they are basically produced by hand and theodolites in the late 1900 century. When the GPS was introduced we all bowed to the surveyors. But still, I would never thrust a chart -"at this scale in a place you have never been before, or at night?"-, and to express it clear: cruising inside a unknown 3 meters curve is not safe.

OCPN is the best and with the developers involved and this debate it will keep the lead position. Thanks to all of you.
Håkan

[Ptizef]

Dave
Testing last git with Windows
Bar menu works fine now, including full screen
I also tested with Ubuntu : same good result except full screen . the upper bar never desappears (may be due to Unity ? )

Thanks
Jean Pierre

[bcn]

Originally Posted by bdbcat

Hubert...

re:

"And one additional observation:
Menu enabled and dragging, zooming or just clicking on the canvas will disable the menu.
This under Windows as well. Feature or bug?"

As you discovered, when you push the "Alt" key you get a temporary menubar. The bar will stay visible and active until the next mouse click on the chart, of any type (move, drag, zoom, etc.). Then the temporary menubar will disappear.

Is this intuitive, or too distracting? We could change this to do something else...

Thanks
Dave

For me this a nice feature - helps to maintain the screen real estate. Especially gaining some pixels in vertical.
Screens for plotters should have an aspect ratio of 1:1 anyhow

[Mollymawk]

Everyone, thanks for the feedback on the menus.

I see a late bug slipped in which stopped many of the items from working on Windows, including the fullscreen action several people have commented on. Dave has already fixed this in the current source.

Dave, I have been at sea for a while, but I had prepared a slightly different fix I think may be more robust. I will try to send a pull request this afternoon and see what you think.
I also think your commit 5e39988 may have been unnecessary - didn't d57914c alone fix the problem, including the fullscreen toggle? For me a similar change seemed to fix it.

I am not sure that always keeping the toolbar visible in fullscreen mode if it is enabled is a good idea (d581f2c). Maybe in fullscreen it can auto-hide, or hide until Alt is pressed? Or this could be an option? (Though too many little options is a nuisance, so maybe not...)

I agree an option to hide the toolbar would be useful, since with the menu bar enabled it is not really needed and it takes up a lot of space on the screen.

petter5:
The statusbar text is supposed to shrink in narrow windows so it is not clipped. In your left-hand screenshot you can see that the text is not all visible because each field is clipped by the next one. In order to avoid this the text shrinks.
This is not (supposed to be) new behaviour in the latest beta, it was already supposed to do it in older versions. For me 3.3.2302 shrinks the text as in your right-hand screenshot, so I am surprised to see it didn't for you.
If you maximise the window you will see the text get bigger, as big as it can get and still all fit in.

Dave:
I love your blurred-lines modified screenshot. Can we do a similar effect (slightly less exaggerated, perhaps) on overzoom in OCPN? So when overzoomed, the lines would get bigger and blurrier like when overzooming a raster chart? This would make it very obvious it was overzoomed.

Cheers,
Caesar

[bdbcat]

Caesar...

re:
"I also think your commit 5e39988 may have been unnecessary - didn't d57914c alone fix the problem, including the fullscreen toggle? For me a similar change seemed to fix it."

I was surprised to need this also. But it seems a bug in wxWidgets. Without this patch on linux, all is well with F11 if menubar is off, or on. But if options->Enable Menu is once activated, and then later de-activated, then F11 does not work. Widgets is somehow processing the event again, due to the Skip() method call, thus cancelling the toggle. This happens even though the menubar was disabled and destroyed. Some state logic in wxWidgets does not get reset, apparently. So this patch is a workaround.

I did not yet test on Mac, on the plan today.

re:
"I am not sure that always keeping the toolbar visible in fullscreen mode if it is enabled is a good idea (d581f2c). "

This is just a question of consistency. The Options->UI dialog says that menubars are enabled. So they should be visible in all screen modes, I think. If one really wants the real estate, disable the menubars globally and use <Alt>.


Anyway, if you have other ideas, I'm glad to consider them.

Dave

[rgleason]

Regarding the Menubars question, after download and compile for Windows (don't know at what point in development, but it is post #46) and the ALT key toggled the menubar.

I was interested in if the menubar check under options would uncheck or not and was looking at that to see if it would uncheck when I toggled ALT and disappeared the menubar, etc. It seemed to be independent the way I was doing it, so I just stopped playing with it.

Now I am told it is a Global settting.... so there are two levels I guess,
1. The Options Menubar has to be checked to even get a menubar.
2. Then you have to hit ALT to make the menubar appear and disappear?

Is this to keep the program faster for slower devices that don't want the menubar?
If not, I think it might be simpler to have the Options > Menubar checkbox and the ALT command directly connected.

I have troubles sometimes with multilevel stuff and I like it simple, but I don't want to cause slowdowns for the program!

Just my opinion. I can live with either. Dave, I am sorry about the wxWidget complications....what a thing to live with.

===========

RE Charts issue. Maybe there is some easy way to make charts more accessible on O's website?

Maybe have US Regional download links for RNC and BSB?

Maybe have a place to purchase a good general world wide chart at reasonable cost (if only it existed), so new users start out with something. (Here is an opportunity for the S-67 plugin maybe. What new user wouldn't purchase a World wide chart for some very reasonable amount just to get started?) Need some BSB or RNC world wide scale chart system that could be used with some confidence for ocean navigating (That is exactly what the earlier NSA(?) chart effort was about, but it got snubbed unfortunately.)

Then use the S-67 plugin system for harbors, or any free RNC or BSB for the given country if it exists.

At least there are more options now. ---I Need to look at current Charts page.

[bcn]

Originally Posted by bdbcat

re:
"I am not sure that always keeping the toolbar visible in fullscreen mode if it is enabled is a good idea (d581f2c). "

This is just a question of consistency. The Options->UI dialog says that menubars are enabled. So they should be visible in all screen modes, I think. If one really wants the real estate, disable the menubars globally and use <Alt>.

Dave

I second this.
With the patch everything ok on the ARMhf platform now.

Hubert

[Hakan]

Hi
I just pulled and had to correct a Win error in FontMgr.cpp. The following change solved it for me but there may be another way to fix it?

@@ -182,7 +182,7 @@ wxString FontMgr::GetSimpleNativeFont( int size )
 //      nativefont = _T ( "0;-11;0;0;0;400;0;0;0;0;0;0;0;0;MS Sans Serif" );
 
     double asize = -size * 96.0/72.0;
-    lfHeight = int(asize);
+    LONG lfHeight = int(asize);
     
     nativefont.Printf( _T("%d;%ld;%ld;%ld;%ld;%ld;%d;%d;%d;%d;%d;%d;%d;%d;"), 0, // version, in case we want to change the format later
             lfHeight,            //lf.lfHeight

Håkan

[bdbcat]

Håkan

You got it right. This one slipped by me.
Fixed in github now.

Thanks for the catch.
Dave

[Mollymawk]

Originally Posted by bdbcat

Caesar...

re:
"I also think your commit 5e39988 may have been unnecessary - didn't d57914c alone fix the problem, including the fullscreen toggle? For me a similar change seemed to fix it."

I was surprised to need this also. But it seems a bug in wxWidgets. Without this patch on linux, all is well with F11 if menubar is off, or on. But if options->Enable Menu is once activated, and then later de-activated, then F11 does not work. Widgets is somehow processing the event again, due to the Skip() method call, thus cancelling the toggle. This happens even though the menubar was disabled and destroyed. Some state logic in wxWidgets does not get reset, apparently. So this patch is a workaround.

I did not yet test on Mac, on the plan today.

Ah, ok, I hadn't seen that strange bug.

I have tested on Mac, it is fine.

re:
"I am not sure that always keeping the toolbar visible in fullscreen mode if it is enabled is a good idea (d581f2c). "

This is just a question of consistency. The Options->UI dialog says that menubars are enabled. So they should be visible in all screen modes, I think. If one really wants the real estate, disable the menubars globally and use <Alt>.

Yes, I can see the dilemma there. That's why I suggested an option, like the one for the toolbar, to choose whether to keep it visible in fullscreen. But of course on the other hand too many little options is a nuisance.
Perhaps one solution would be a dropdown:
Show Menu Bar : Always / Never / Except fullscreen

That said, I don't think the way it is is a massive problem. On Windows I will probably keep it disabled and only use it with Alt.

Originally Posted by rgleason

Now I am told it is a Global settting.... so there are two levels I guess,
1. The Options Menubar has to be checked to even get a menubar.
2. Then you have to hit ALT to make the menubar appear and disappear?

Rick, this is not the case. Rather:
- If the box is checked, it is always visible.
- If the box is not checked, it is hidden but can be shown temporarily by pressing Alt (and hidden by pressing Alt again, or clicking anywhere on the chart).

Caesar

[bcn]

Originally Posted by rgleason

Maybe have a place to purchase a good general world wide chart at reasonable cost (if only it existed), so new users start out with something. (Here is an opportunity for the S-67 plugin maybe).

Does not exist . There is no "CM93 cheap set in S-63 format". Nice to have, but nobody is licensing it. Such is life...
There are challenges left.

[rgleason]

Rick, this is not the case. Rather:
- If the box is checked, it is always visible.
- If the box is not checked, it is hidden but can be shown temporarily by pressing Alt (and hidden by pressing Alt again, or clicking anywhere on the chart).

Caesar

Caesar, Thanks for clarifying, is there anything like this in the rest of Opencpn?
I am still pretty confused.
Under Options > User Interface

• Show Status Bar
• Show Menu Bar
• Show Compass /GPS Status
• Show Toolbar in Fullscreen Mode

When I check "Show Menu Bar" - Nothing happens when I hit "Apply" but when I hit "OK" and Options/UI Closes and the "Menu Bar" shows whether it is in full screen or not. Hitting "Alt" does not toggle the "Menu Bar" on or off. It just stays on.

When I then check "Show Toolbar in Fullscreen Mode" with "Show Menu Bar" checked, nothing changes, the "Menu bar" shows whether full screen or not. "Apply" does not change anything. "Alt" does not work.

When I uncheck "Show Menu Bar" leaving "Show Toolbar in Fullscreen Mode" checked , when in full screen mode and hit "Apply" nothing happens. When I hit "Ok" the UI disappears and so does the "Menu bar". I can hit "Alt" and the "Menu bar" toggles on and off in both full screen and partial. However going from partial screen to full screen, the "menu bar" does not appear.

I am not sure I am using most current version as I am one git behind I believe.

I think we should put these two commands together, call them the same thing, if they are intended to be operating on the new "Menu Bar" and make it clear to users in the menu what they are supposed to do, and then actually do it. (I know this is a work in progress...!!)

If you want to make this simpler it might become clearer. ( I don't think we need the automatic adding of the "Menu Bar" when in full screen. I think if the "Menu Bar" box is checked the "Menu Bar" remains visible, just as you stated, full screen or not. If the "Menu Bar" is not checked, the "ALT" key works to toggle it on and off.

So what is the "Show Toolbar in full screen mode" ? Is this referring to the Iconbar? Not sure about its function now.....

In any case, I guess we should sort it out and an explanation in the manual.

Should I git a newer version now and try it?

[bdbcat]

Rick...

Current github is complete with respect to menubar and toolbar.

We do not have the option of globally disabling the toolbar, and I don't think we ever will. We can disable the toolbar in fullscreen mode, although I would not mind seeing this option disappear.

O is, and must be, completely usable without the menubar. Always has been, and that is part of the original specification. No fiddly menus that are hard to access in a seaway with a touchpad or trackball. That's why we have big toolbar buttons.

The <alt> shortcut key is really intended to give the user quick access to the menubar for maybe one simple command. Not meant as a toggle.

So, step back a pace, have a beer, and try all the options alone and in combinations. Note variations from intuitive expectations, one by one. If the options dialog wording does not match the expectation, then let us know. This is evolution, not revolution.


Thanks
Dave