Sean Depagnier's Plugins

[yachtvalhalla]

Originally Posted by boat_alexandra

There is no error. The video gives the same description as in the actual plugin which is exactly what the display is. Each barb is 5 knots of wind.

The description you listed came from somewhere else. Should the plugin use beaufort scale instead?

The image I uploaded is from the Pilot Charts of the world. And yes, the Beaufort scale is what the barbs display and should be used.

Five barbs means Beufort scale of 5 which is a fresh breeze of 17-21 kts.

https://en.wikipedia.org/wiki/Beaufort_scale

Sorry, but I think it's best to be accurate.

Terry

[seandepagnier]

I just wanted to point out, it is not an error in the video. Climatology plugin always used 5 knots per barb, and was documented this way.

I can change to beaufort scale, but I personally find it more confusing... before I could just multiply the barbs by 5. What is the advantage other than to conform to other pilot charts?

I will likely make this a display option (checkbox) for wind atlas. The question now, is which default value to use.

[yachtvalhalla]

Originally Posted by boat_alexandra

I just wanted to point out, it is not an error in the video. Climatology plugin always used 5 knots per barb, and was documented this way.

I can change to beaufort scale, but I personally find it more confusing... before I could just multiply the barbs by 5. What is the advantage other than to conform to other pilot charts?

I will likely make this a display option (checkbox) for wind atlas. The question now, is which default value to use.

For us older sailors that used Pilot Charts for route planning (as I did with a stack of heavy paper) and then had the convenience of the VPP program, we are used to the traditional wind rose. But I doubt if many sailors today have ever viewed the paper Pilot Charts.

Using 5kts per barb overstate the wind.strength a bit. Using the Beaufort scale the number of barbs equates to wind strength as:

Barbs Wind strength(kts)

3 7-10
4 11-16
5 17-21
6 22-27
7 28-33

And since these wind strengths are averages over many years its foolish to think that's what you will find. So the scheme of multiplying the number of barbs by 5 is a good approximation and yes, a lot more convenient for the sailors of today.

Don't change anything.

It's just that using the same graphic as the traditional wind rose caught my attention since I'm probably one of the few who spent hours pouring over those wind roses and used the Beaufort scale as the intuitive strength (which I would be surprised to encounter).

So we can this one under the rug.

(Never thought I'd find a use for that emoticon!)

Terry

[rgleason]

Sorry Sean, I should have noticed that difference.
I think you should have an option checkbox to show wind in Beaufort and keep the plugin default as it presently exists.

[rgleason]

I have been trying to maintain Sean's Plugins, with the help of other programmers. Sean's interest has been on other projects, so his help has been dramatically reduced for some time. Jon Gough has been hugely helpful to me in creating and maintaining Frontend2 which I have been using, and Alex Leamas and Dave [bdbcat] have been very helpful resolving issues, but I can''t continue to ask them to divert attention from OpenCPN.

The new Plugin Manager supports more build environments than I have interest in and can support with my limited programming knowledge, and the reduced interest in maintaining these plugins.

1. I am finding that the previous programming assistance from capable programmers who are not working on the main program has completely "dried up".
2. Testing and deployment for so may builds is totally impractical for me.
3. Deploying untested plugins creates the impression that OpenCPN is broken.
4. Additionally every change to the plugin frontend brings changes to the main body of the plugin and issues that must be resolved for each of the built environments. This is unavoidable and expected.
5. As OpenCPN changes, more dramatic changes are on the horizon.

Therefore some changes are necessary as I can't keep up alone, without programming help from active users who are not programming the main program, OpenCPN, and I am not going to ask for help from that direction.

1. Windows will be built.
2. Only Unix, Ubuntu and RPI builds that complete easily are going to be deployed. The others will not be deployed.
3. Android builds are not going to be done because special programming is needed to get those working even if the environment completes.
4. MacOS plugins are not going to be built because I don't have that environment and I don't want to deploy files that don't work.
5. As a result a number of builds will be commented out in ci/config.yml
6. The environments deployed will vary from plugin to plugin, depending on results.
7. I will accept PR's for undeployed builds provided they have been fully tested and do not affect the other builds.

Sorry about this, but the only other option is to just stop.

[Tupaia]

A wise decision that I am sure the majority will support you on. It will focus development instead of detracting by having to test on so many platforms.



I also think it will also encourage more people to become involved in development as the current number of compile options has become overwhelming.

[rgleason]

Thanks Tupaia. I hope that MacOS users will participate more than previously in testing and correcting, and making PR's for plugins.

Accordingly I am going to amend my NOTICE below for testing of MacOS and the other build environments that I have identified previously as "not tested" and ""not supported", as I work through Sean's plugins:

1. Plugins that build MacOS successfully, will be uploaded to the respective OpenCPN Plugin Cloudsmith directory where the xml and metadata files can be found.
2. Users should test these plugins and advise if they work properly. The user must include the exact files used with a link to them in Cloudsmith and a description of how it was tested. Additionally, I expect that this test is for the Plugin Manager xml and metadata files.
3. Then I may decided to add them to the Plugin Manager.
4. As I work through Sean's Plugins, the webpage "Plugin Downloads" page with have Opencpn v5 links for MacOS removed until users confirm that the Cloudsmith plugin works.
5. The same procedures will apply to Android, rpi, and any Ubuntu builds that are not added to Plugin Manager

I would entertain a dedicated team of MacOS users who test and improve the plugins for MacOS.

[rgleason]

I am asking MacOS users to test all of Sean's plugins using the Plugin Manager version only, not the pkg version, and advise which ones work. I will remove these on monday. If I don't hear from anyone I will have to remove them all.

The sAmerican applies to rpi and android..

[Rasbats]

Rick...

A little premature perhaps?

Mea Culpa ... it was my setup that led to doubt about Sean's plugins which are using a wxWidgets menubar. It was the MacOS menubar that was causing me problems. My Mac Mini is now working correctly.

Weatherfax has been well tested and proven to work correctly on a number of other machines. It is likely that the other plugins, if they compile for the Mac, will run successfully. Could we wait for bug reports before any further action is taken? Happy to work on Mac bugs, where I can.

Mike

[CarCode]

There are obviously Mac users which claims even the main program OpenCPN v5.2.4 crashes with their machine. They say it was a Mac with core2duo cpu but with a macOS version which should work. I do not have such a CPU for my Mac machines.
I guess first such issues should be investigated before someone cares about plugins.


Furthermore several users claimed about missing or wrong user manual. They did not find the supplemental file for 5.2.4. If you want to help OpenCPN Rick, then you should start with the roots.

[hoolie]

CarCode, I think it's clear you know more of the Mac implementation than Rick who AFAIK is mainly a Windows man. So why don't you make more of a positive contribution by providing/updating the necessary Mac support documentation? It really doesn't help to keep carping on about things you yourself could or should sort out.

[CarCode]

hoolie
I do and I have. But I have my own manual version, own OpenCPN version, own plugin versions and so on but only in german language and using the genuine programing tools of Apple (Xcode) and not the third party tools like circleci, appveyor, flatpack, cmake or whatever they are called. I am using also other supplementary libraries such as another wxWidgets version. So my own work has no benefit for any one else.
You must allow me however to point to faults happening here. If not simply do not read my postings.

[hoolie]

OK fair enough. And I will continue to read your postings!

[rgleason]

Thanks guys I will hold off removing those xml files from opencpn/plugin for the Plugin Manager, but would appreciate having MacOS, rpi and Android confirmations that Sean's plugins that are available in the Plugin Manager actually work!
I need a list of the ones that work (or the ones that don't work).


As you all know I am flying blind with respect to MacOS, rpi and android and do not want to liter the catalog with bad plugins. So I need some help and cooperation. Thanks very much.

[ohthetrees]

I'm not technical, and a noob besides. As a new mac user, I'd love if some of these plugins worked (I'm particularly interested in the celestial navigation plugin). However, if a plugin doesn't work, let me humbly suggest that it shouldn't appear in the plugin manager. It took a lot of poking and prodding installing/uninstalling/etc before I realized after some googling that the Mac version of celestial navigation doesn't work/install. Would it not be better to have it not even show up as an option in the mac plugin manager? Or give a prominent notice that it doesn't work on mac?

If I've misunderstood anything, my apologies. I'm well aware this is a generous volunteer effort of a free product, so I am not criticizing anyone.