OpenCPN Version 4.0 Released

[Wrong]

Originally Posted by Wrong

The way you make it sound, I must be the only user of OpenCPN, regardless of platform who've never had issues with screen settings.

I think it's a bit disengenuous to suggest these changes primarily, originally have anything to do with correcting displays across the board. It has been driven due to problems displaying OpenCPN on Windows tablets. Ironically, my 'too difficult for the average joe installation' of linux and OpenCPN on androids has none of the problems these changes are supposed to resolve. The changes are however making it impossible to use OpenCPN updates on androids...

You've got a Windows version of OpenCPN, so why not restrict these experiments in using Windows tablets to it? Why apply it accross the board?

I hardly believe having a ruler to measure with would have required anything more than a plugin.

Finally, I think trying to get ahead of the game where anticipated hardware development is concerned is a fool's errand. Focusing on more dense pixel displays - anticipated to arrive in the future - is hardly relevant in trying to keep OpenCPN useable for everyone as an aid to navigation.

I just want to add this new feature due to it's potentially unpredictable, disruptive effects should be subject to a user's choice to enable or not. It should not be active upon OpenCPN's launch.

[wgewaldii]

Originally Posted by weinie

Don't know if anyone else had this issue but....

on the download page, there was a banner ad with a "download" button that didn't looked like the actual download button. Turns out it was nasty malware.

I ran malwarebytes and it cleaned everything up, but not until installed 5 or 6 "programs" that wouldn't uninstall and making my browser go haywire.

That happened to me, got a warning message from McAffee.

[RhythmDoctor]

Originally Posted by bdbcat

wdkester...

This behaviour is by design. The idea is that import and export of routes is not a frequent thing, generally. And we want to see all the info from "foreign" routes coming into OCPN. There really is not much reason to export and then re-import a route into O. If it is not wanted on the screen, just hide it in the RouteManager...

FWIW, I am exporting and importing routes all the time. It is the most reliable way to ensure that the route will always be available, and not wiped out by the occasional crash.

While it is true that in theory I could go into route manager to hide all my routes except the one(s) I want to see, this would be a very long list if my routes are all open. It is much easier to just right click the route on the chart (or touch-hold on a tablet) and select delete. That way you don't need to go into route manager at all. You don't even need to know the name of the route - just delete the one you see on the chart. Much easier.

I believe that the waypoint numbers always showing can create unnecessary clutter, especially when zoomed out far. There should be a way to turn them off, preferably by default.

[yachtvalhalla]

The 2bells timing is so close together it sounds like 1bell.

Terry

[seandepagnier]

Originally Posted by yachtvalhalla

The 2bells timing is so close together it sounds like 1bell.

Terry

Is this different from a previous release?

Does it sound the same as playing data/sounds/2bells.wav ?

The change was to now use timing logic for more than 2 bells as it repeats the 1/2 bells sounds to make a given number of bells and saves about 1MB from the opencpn package.

[yachtvalhalla]

Originally Posted by boat_alexandra

Is this different from a previous release?

Does it sound the same as playing data/sounds/2bells.wav ?

It's been the same previously but I had not used this feature very much before now.

Yes, the 2bell .wav file is the same which needs the delay put in between the two bells. You have to be concentrating on the sounds to hear a very slight difference .. not what you would normally be doing.

Terry

[fgd3]

Originally Posted by bdbcat

There really is not much reason to export and then re-import a route into O. If it is not wanted on the screen, just hide it in the RouteManager.

I offer this as another data point to help you understand how others use OpenCPN.

I treat "export" like "save" and "import" like "load". When I am not using a route I delete it. If I want to use it again I import it. My exported routes are a library of unique segments which can be used as building blocks for an end-to-end route. Just as I don't want my screen cluttered with a lot of routes I'm not using, I don't want the route manager filled with a lot of routes not currently needed.

When I build a route I edit the waypoint properties so each waypoint has a unique name that is compatible with my Garmin GPS 72. If two routes share a waypoint I make sure to "Use nearby waypoint". That allows me to upload routes to the GPS 72 without creating a lot of redundant waypoints.

For planning purposes I might join (extend) several routes so I have the total travel time, but I wouldn't upload the combined route to the GPS 72. I would just activate the route segments as needed.

Underway I use the GPS 72 for navigating. In pilot waters, especially when running the engine, I run OpenCPN on the laptop. I don't run the laptop during passages because it draws too much power. I wouldn't want to use the laptop in bad conditions because it isn't water proof. The GPS 72 is made to be used in the cockpit even in wet conditions.

If I have OpenCPN running I sometimes create short routes while underway. I view those routes as temporary and delete them at the end of the day. I view OpenCPN as a workspace where I can make any changes without affecting what is stored in my library. The file of exported routes is my library and I change its contents only when I want to make a permanent revision.

Fabbian

[wdkester]

I operate pretty much the same way as Fabbian does. I even use a Garmin 72.

In the good old days there were performance problems when you had thousands of waypoints, routepoints, and tracks. You really had to reduce what was loaded. I think the performance problems are in the past.

I operate more or less the same way I did then, only now the reason is to reduce clutter. You can hide routes and tracks (marks are more tedious) on the chart, but they still clutter route manager.

I do sometimes include some information in a mark name, but when creating routes, the names are mostly consecutive numbers, which convey no useful information.

[PjotrC]

Originally Posted by fgd3

I treat "export" like "save" and "import" like "load". When I am not using a route I delete it. If I want to use it again I import it. (...) Just as I don't want my screen cluttered with a lot of routes I'm not using, I don't want the route manager filled with a lot of routes not currently needed.

Same here... (and I also use a Garmin72).

Another point: hidden routes and marks are often a major nuisance, because when building a new route or dropping a mark the invisible marks are offered for selection... so I try to have as few of them as possible, and I use hide/show only for specific tasks, usually just for a moment.

I was about to report this as a bug, because the user is then asked an impossible question: "do you want to reuse this mark?", without showing what the mark is...

Also, hidden objects are not subject to "export all", so it is still easier to "delete all" than "backup all". I know, it's on the list, but life is not getting easier...

[nohal]

Originally Posted by PjotrC

I was about to report this as a bug, because the user is then asked an impossible question: "do you want to reuse this mark?", without showing what the mark is...

Please do so, as it is one...

The workflow where you have a problem with the names being treated is if it was a GPX file not coming from OpenCPN is well understood, the solution simple, just stay tuned.

Pavel

[fgd3]

David,

My routes usually run from one nav aid to another and the names I give to the waypoints refer to the nearest nav aid. When I see that waypoint in the GPS 72 the name helps me remember it. It also makes it easier to go to a waypoint from an arbitrary location. If I use the sequential waypoint numbers assigned when creating a route they will show up on the GPS 72 with names like R4002. Then if I delete that route from the GPS 72 and upload a replacement it may be assigned a different route number, causing all the waypoints to be duplicated with names like R6002. By naming waypoints carefully I avoid the GPS 72 creating needless duplicates.

I've attached a sample route for anyone interested (remove the .doc extension). Waypoint SK68 is the Siesta Key daybeacon "68". ANAMAR is the Anna Maria bridge. I always have waypoints for ICW bridges so the GPS can give me an ETA. That tells me if I need to speed up or slow down to make a scheduled opening.

Fabbian

[wdkester]

Fabbian

" I always have waypoints for ICW bridges so the GPS can give me an ETA. That tells me if I need to speed up or slow down to make a scheduled opening."

Great idea! I hope to be going down the ICW next Fall an I, for sure, will name the lift bridges.

I might even bother to put the bridge schedules in the WP comment field.

Another trick - I create WP with a colorful symbol for the problem areas, as identified by The Salty Southeast Cruisers' Net. I then put their write-up of the problem in the comment field. It would really be neat if a rollover would display the comment field of a WP, but a double click will get you there. I should also say that on the ICW and other restricted waterways, I run OpenCPN on a laptop in the cockpit.

[Wrong]

Originally Posted by bdbcat View Post
Wrong...

Well, I guess I am an average Joe, because Linux Deploy did not work for me. Nicely rooted Android 4.x tablet, otherwise works fine. Linux Deploy refused to download and configure any linux image, no logfile, no help screens, no nuthin. Just "Updating configuration...done..." Over and over...

I have another tablet that runs debian natively, using a custom boot image and sdcard. LXDE desktop. No OpenGL capability. I built O4 on this tablet using the current github master and native GNU tools. Ownship displays just fine. No problems observed in quick test.

So, I'm stumped.

Any hints?

Thanks
Dave

Originally Posted by Wrong

First Dave, I'm honoured by you giving it a go.

Which tablet and android version of 4.* are you using?

I don't delve much into the rooting process in my instructions because they differ considerably. I assume the developers are pretty thorough when explaining SuperSu settings. But, maybe not.

Depending on your version of android, SuperSu is either installed seperately from the ROM, or as in the case of Cyanogenmod included in their custom ROMs along with a 'Privacy Guard'.

Access by applications to system files is controlled by SuperSu. The Privacy Guard is used to prohibit applications from accessing your 'private data'. Both are user controlled.

If the rooting process you used required you install SuperSu seperately there will be a SuperSu icon on the android desktop where all applications reside, not your customized desktop where you've placed frequently used applications.

Tapping on the icon opens the SuperSu app. Go to the settings. Scroll Waaaay down toward the bottom until you see something akin to 'enable SuperSu Pro'. Enable this option. Right, you don't need to buy the Pro version because while the developers appreciate people who do, they also realize the indespensible need by owners of rooted devices to use the app.

In Cyanogenmod's Custom ROMs, the SuperSu and Privacy Guard options are accessed through 'System Settings', typically opened by tapping on a gear type icon...

If Privacy Guard is enabled for Linux Deploy, it may not work. And of course, SuperSu must be installed with the 'Pro' version enabled.

Whenever an app requiring access to system files is opened the first time, SuperSu will appear asking you what to do. Grant or Deny access to the app? Permanently, or for some pre-determined amount of time? If this did not happen when you first opened, or tried to do something with Linux Deploy that required access to system files, it's most likely related to my discussion above.

Which tablet is running linux natively?

If this doesn't resolve your problem come back and I'll help to get it going for you...

Dave,

Giving you the benefit of the doubt your experience with Linux Deploy is not a configuration or procedural problem...

Did my posted reply about SuperSu solve the issue?

There should have been a log on 'sdcard' if you enabled logs in L.D..

[PjotrC]

Originally Posted by yachtvalhalla

Yes, the 2bell .wav file is the same which needs the delay put in between the two bells. You have to be concentrating on the sounds to hear a very slight difference .. not what you would normally be doing.

Terry

Seems that music perception is a very subtle thing indeed... Very often one hears that "something is wrong here", but a statistician or an engineer will insist that the device performs well...

Definitely the sound of 2*1bell will be different from 2bells, 2*2bells will be different from 4bells and again the sound of 2bells (in reality) will be different, depending on how one does the striking (there are two basic ways of doing this). It is not difficult to hear the difference.

If saving space in the installation kit is critical, one could remove the .wav files completely, and offer - as a minimum - 1bell.wav and 2bells.wav for download from the opencpn.org site.

Honestly, I think the bells included in WxTides sound better, but I did my best to produce sound files that would be legally cleared for use with OpenCPN.

My choice would now be to revert to original implementation, and offer the 1bell to 8bells wavs for separate download.

In my experience, on a bigger ship, where power is of no concern, striking the bells is about the main feature needed from a chartplotter for hours and hours on during an ocean crossing ...

[nohal]

I have prepared a modified version of 2bells.wav for the 4.0 service release.
You can get it from https://github.com/nohal/OpenCPN/blo...s.wav?raw=true

Let me know if you will be happy with it...

Pavel