OpenCPN Beta Version 4.5.307

[bdbcat]

Ahoy, OpenCPN'ers...

OpenCPN Version 4.5.307 Release Candidate 1 will soon be available for download from opencpn.org.

Monitor the opencpn.org Downloads page to find and download the latest binaries.....

Or download directly here:

http://opencpn.navnux.org/beta/openc....307_setup.exe

http://opencpn.navnux.org/beta/OpenCPN_4.5.307.dmg


Source is available now on github at:
https://github.com/OpenCPN/OpenCPN
Branch: master
Tag: Beta_v4.5.307

4.5.307 Beta Release Notes

49. Extract and integrate User Manual from present dokuwiki contents.
50. Improve text formatting of initial Welcome dialog.
51. Improve Busy Spinner logic to avoid "orphan" spinners.
52. Implement minor improvements to ENC rendering rules, especially for OpenGL mode.

Notes:

1. The embedded User Manual is a significantly richer than the previous versions, and so is a bit larger.
There may also be some missing/broken links. Please take a look, carefully noting any critical sections or images missing.

2. This Beta is considered to be the first Release Candidate.
All features are frozen.
Unless fatal logic flaws are discovered, only minor changes (e.g. message strings, trivial rendering troubles) will be considered for the final release of OCPN 4.6.

Thanks for your continued testing efforts, and ...
Good Luck

Dave

[transmitterdan]

Dave,

I have built from today's git and found a new problem. If I request to rebuild chart database whilst also receiving NMEA data via UDP then when the chart rebuild is complete no more NMEA data is processed. If I disable and then renenable the UDP connection the processing resumes as normal. Somehow the connection is dropped and not restored automatically.

I believe this is new behavior but not sure when it started. Would be good if someone else could replicate to see whether mine is a one-off case or not.

System: Windows 10 - 64-bit AMD (relatively weak processor)

[Hakan]

dan...
Yes I can confirm the scenario. The UDP connection is not resumed after a chart data base rebuilt but the serial connections, including AP output, was though resumed.
If this is new I can't say since I've never got the idea to rebuilt while receiving data. Definitely not while sailing and dependent of a functional navigation system?
Håkan

[transmitterdan]

Ok, I will try to debug the issue.

[CarCode]

Once again, now with your new Welcome dialog, see attachment.

Is it really so difficult to learn programming?
Remember:
- don't use horizontal alignment flags together with wxWXPAND
- don't use vertical alignment flags together with wxWXPAND
- don't use horizontal alignment flags for horizontal sizers
- don't use vertical alignment flags for vertical sizers

Gerhard

[Hakan]

Gerhard
Even if advanced programming is easy for you please be patient with us not so skilled.
I'm not skilled at all but have some simple understanding and at least I know how to make a push request when I've a humble suggest.
So, if you want a lesson how to perform a PR to GitHub please advice.
Håkan

[CarCode]

Originally Posted by Hakan

Gerhard
Even if advanced programming is easy for you please be patient with us not so skilled.
I'm not skilled at all but have some simple understanding and at least I know how to make a push request when I've a humble suggest.
So, if you want a lesson how to perform a PR to GitHub please advice.
Håkan

Hakan,
when it was the first time I have pointed to such things I can understand you. But I have wrote this several years ago already and nothing has happened.
Always the same faults have been done, that's all.
More than 10 years ago a nice book about wxWidgets was released:
"Cross-Platform GUI Programming with wxWidgets"
You can find it even for free as eBook in the Internet, search with Google:
https://ptgmedia.pearsoncmg.com/imag...73816_book.pdf

Even when the book is more then 10 years old it is still worth reading and can avoid many of the faults still made here.

I dislike people which are ignorant and arrogant.
And don't tell me I should do push requests to github when a few times later the same faults are done again as seen here in this example.

Gerhard

[transmitterdan]

Gerhard,

I am fixing all these things but will wait until we get 4.6 out the door to make a PR. There are about 4 dozen little things like this. Fortunately the regular user remains blissfully unaware about these asserts since they only generate action in debug mode.

[transmitterdan]

Originally Posted by transmitterdan

Ok, I will try to debug the issue.

So it seems this is an old problem based on a review of the connections logic. I will work out a solution but it will have to wait until after 4.6 is out.

Notes: it seems the wx sockets subsystem does not generate a timeout event as it should so it may take a little digging to find out why. Also, the watchdog system is set up to work in TCP mode but not in UDP mode.

[CarCode]

Originally Posted by transmitterdan

I am fixing all these things but will wait until we get 4.6 out the door to make a PR. There are about 4 dozen little things like this. Fortunately the regular user remains blissfully unaware about these asserts since they only generate action in debug mode.

Thank you,
yes I know, there are several of these little things. The one I mentioned here was only an example. I was angry only because these faults always comes up again and again.

Gerhard

[transmitterdan]

Gerhard,

If you don't mind you could help me. Please clone https://.com/transmitterdan/OpenCPN and build branch DanBugFix. Tell me if you get any asserts under MacOS. I don't have a MAC to test. This branch has all updates from Dave plus my attempt to remove all asserts. I am also making this branch compatible with WX 3.1. On Windows it builds and runs against WX 3.1 with no issues.

[CarCode]

OK, I will try.
However I also use the Sierra SDK (10.12.3) and Xcode 8.2.1.
Just downloading your version right now.

Gerhard

[bdbcat]

Gerhard, et al...

The wxASSERTS you report are part of wxWidgets 3.1.0.

OpenCPN 4.5.x and soon to be released 4.6.0 use wxWidgets 3.0.2.

So, the problems you report are not critical to the current Release development effort. We may move to wx3.1 for the next major release cycle of OCPN, although there is not much motivation to do so. There are no new classes in wx310 that I can see which would help us. There are no bugs in wx302 that are blocking us. WX310 is not yet available in the popular linux distribution repos. And finally, there are surely bugs, known and unknown, in wx310.

However, the prime focus for OCPN development is stability of user functionality across releases, while adding perceptible improvements in features and performance. We have tens of thousands of users worldwide who require a smooth, reliable upgrade path.

So please do not compare your private Mac build with wx310 to the official production builds using wx302 without mentioning the critical point that you are using a new, untested version of wxWidgets. It clouds the real issues we focus on.

Of course, if you would like to help in the migration of OCPN to wx310, we welcome the input.

Thanks
Dave

[CarCode]

Originally Posted by bdbcat

Gerhard, et al...

The wxASSERTS you report are part of wxWidgets 3.1.0.

OpenCPN 4.5.x and soon to be released 4.6.0 use wxWidgets 3.0.2.

So, the problems you report are not critical to the current Release development effort. We may move to wx3.1 for the next major release cycle of OCPN, although there is not much motivation to do so. There are no new classes in wx310 that I can see which would help us. There are no bugs in wx302 that are blocking us. WX310 is not yet available in the popular linux distribution repos. And finally, there are surely bugs, known and unknown, in wx310.

However, the prime focus for OCPN development is stability of user functionality across releases, while adding perceptible improvements in features and performance. We have tens of thousands of users worldwide who require a smooth, reliable upgrade path.

So please do not compare your private Mac build with wx310 to the official production builds using wx302 without mentioning the critical point that you are using a new, untested version of wxWidgets. It clouds the real issues we focus on.

Of course, if you would like to help in the migration of OCPN to wx310, we welcome the input.

Thanks
Dave

You are wrong. Please read the wxWidgets eBook. It is dated from 2005.

Gerhard

[bdbcat]

Gerhard...

The ASSERT in your screenshot does not exist in the wx302 source code.

Ergo, a user or developer using the recommended build process will not see it.

Dave