Tactics Plugin

[RonSouthworth]

Originally Posted by rgleason

Ron,

"The process to package is as per the document wilki.
It is very similar to how other open source projects are packaged.. e.g. MuseScore3"

Musescore has a lot of plugins I find. Are you familiar with how they produce these by any chance? Looks like an interesting opensource program!

https://musescore.org/en/plugins

Hi Rick

I have an understanding of how deployment of the base app, plugins and add on's is structured. I am mainly focussed on the base application mainly because of where it is at in its development cycle and feature set.

The plugin API was re-enabled into the base a little while after V3 was officially launched. I have read some developer messages about improving or altering the API, the code to support it. I have not seen that realized into code.

Rather than me list lots of details here the documentation for API version 3as it stands is available (link Below)

https://musescore.org/en/handbook/de...ook/plugins-3x It references the V2 and V1 API respectively.

Lots of Ideas on change management there..

Ron

[RonSouthworth]

Originally Posted by rgleason

Ron, everyone has their own way of doing things, but TransmitterDan has made a python script that will play nmea files just like VDR_pi. In many ways it is better because it is a separate program. I've used it for testing quite a lot. Mac may be different for setup, but it is here:

VDR Server
https://opencpn.org/wiki/dokuwiki/do...rver_for_tests


Thanks for the build info.

What are the critical differences building for Mojav? In terms of setup?

Hi Rick,

I've seen some Python replay of pre recorded event captures. Trade show visions spring to mind. Yes everyone is different. I prefer protocol generating and analysis tools on a separate device, To me it is the ultimate for being able to thoroughly test how something is implemented, It is also useful for showing someone how to use things click n giggle if you like, or what to expect dynamic scenarios and such,

Scripting is more for replay/review of a sequence of events to me, retelling history. I have seen a lot of bugs in digital field instrumentation design missed by using script replay so that is why I am keener on other approaches I guess. If you like click a button and it happens not wait till I load a different script....


Mojave difference?

Simply put, If you want to use all the dark mode frameworks the compiler version you have to use is 10.2 .... All the dependencies need to of course be compiled with the same version. The framework is better at finding prerequisites....

You can run multiple versions of Xcode on a machine I have not tried compiling a backport of OpenCPN.

I have with MuseScore2 and there was a lot of shell prerequisites incl the older library to reference to do it but it worked.

something to investigate.


https://www.computerworld.com/articl...ns-to-you.html


/Ron

[RonSouthworth]

Hi Rick and Dan


PR30 applied to
Tactics_pi on macOS Mojave OS.


/Ron

[rgleason]

TransmitterDan has made some additional improvements..
He's been tagged a "Star" on my github repository for quite some time.


Anyway, these are his most recent changes which build, please add the version numbers to the file names. This is still "TESTING". Thank you Dan!



ov50 = https://ci.appveyor.com/project/rgle...5784/artifacts


ov42 = https://ci.appveyor.com/project/rgleason/tactics-pi

Now click on the TAB Artifacts and download the file and rename it.



I have not tested either of these. Good luck. I should really get the plugin code to name the files next.


@Ron, it looks pretty good. I agree with you re testing tools for different purposes. Thankyou.

[RonSouthworth]

Hi Rick

Indeed

Thanks to everyone for the effort,

Re Testing Suite's

Yesterday I found some Java source code I had tucked away.

The old "Instrumented Vessel Simulator" such a relief,
something that is a known quantity to work from and with and model from as it is overdue for a redesign


Testing the p-30 tactical_pi commits on Ubuntu 19 (Attached).



/Ron

[Canne]

Originally Posted by rgleason

<snip>This is still "TESTING". Thank you Dan!
ov50 = https://ci.appveyor.com/project/rgle...5784/artifacts
</snip>

Thanks Dan and Rick! I have successfully tested https://ci.appveyor.com/api/buildjob...0009-win32.exe on O v5.0.0+9065270 Windows 10 Pro 1809 with a O 4.8 recording of mine. Indicators and history all OK. CPU-load around 2%.

The only issue - non-blocking - I found was with the split screen mode: when moving one of the windows of tactics into the right side pane, it strangely got stuck, in a smaller size, above the GPS indicator. No way to move the tactics window back into the right pane now.




When I changed back to single canvas, the window which was in the right window pane, remained there but maximized. No way to move it.



To get back to normal, it was necessary to disable tactics plugin, then re-enable it and reorganize all its windows.

[transmitterdan]

If you right mouse click on the “stuck” window then click “undock” it will become unstuck.

[Canne]

Thanks Dan, the undocking is indeed the remedy but the root annoyance is that when a tactics window gets moved anywhere over the right pane, it gets suddenly sucked up and docked, filling the upper right part. One cannot just leave it floating over both panes, which is possible with the built-in dashboard. But maybe this is an issue with the temp-build's wxWidgets configuration? Let's wait for the next build, meanwhile I can use a single pane to avoid this issue.

[transmitterdan]

It has to do with the docking code in Tactics_pi. I will fix it in a few days. For now you can place a panel over the left chart area. Then grab the lower right corner and expand it across over the right chart area. It should not dock then. But if you then move the panel using the upper drag bar it will try to dock. So don’t move it once you have it sized across.

[rgleason]

Windows Testers are new appveyor builds which don't have TDan's unsticky menu fix,


ov42

https://ci.appveyor.com/project/rgle...1895/artifacts
please relabel


ov50
https://ci.appveyor.com/project/rgle...1919/artifacts
please relabel

[Canne]

Thanks, Rick, indeed the forced sticky window on the right pane issue remains, I confirm, but the lower right corner resize possibility makes it not critical. When testing on Win10 navigation computer with the boat instruments all shut down (no incoming NMEA sentences), I noticed the sluggish operation again, 30% usage of CPU, continuously. At startup, the previous Tactics_pi configuration with three history windows reopened but they remained blank and unresponsive for quite a while.

[rgleason]

Originally Posted by Canne

Thanks, Rick, indeed the forced sticky window on the right pane issue remains, I confirm, but the lower right corner resize possibility makes it not critical. When testing on Win10 navigation computer with the boat instruments all shut down (no incoming NMEA sentences), I noticed the sluggish operation again, 30% usage of CPU, continuously. At startup, the previous Tactics_pi configuration with three history windows reopened but they remained blank and unresponsive for quite a while.

Humm, which version are you using? ov42 or ov50? -- I see it is ov50


also, does this occur with the immediately previous version? (IE we may have a reversion)

[Canne]

ov50. From today. I did not test earlier appveyor version without the instruments. I think the issue was there already. My regression testing is miserable, sorry...


Back to the boat, re-test:


When I start ov50 with the instruments on and computer connected, Tactics_pi history windows reopening, ov50 starts quickly and so does Tactics_pi. CPU load calms down for the process pv50 very quickly.


Stopping ov50.



I disconnect the computer from the instruments and restart ov50. Sluggish behavior and high CPU load as reported above. I reconnect the instrument USB cable. After a few minutes ov50 catches up and so does Tactics_pi, CPU load goes down to 2 - 4%.


Stopping ov50. Disconnecting the instruments. Restart ov50 and try to replay NMEA sentences from the recording. Replay works and the chart position moves to the recorded position but Tactics_pi never catches up and the CPU load remains around 30 % for ov50 process.


Hope this clarifies.

[rgleason]

Canne, thats ok. Nothing has changed.

For ov42 see
https://github.com/rgleason/tactics_...ation?expand=1

and
https://github.com/tom-r/tactics_pi/...ation?expand=1

For ov50 see
https://github.com/rgleason/tactics_...ation?expand=1

Note that github purposefully misses the changes in appveyor.yml which builds the ov50 version.

So in short,there is no regression, I think we've got to figure out what is causing the problem.
It's pretty clear the problem is when there is not the expected nmea data on the bus, the plugin does not appreciate that.
I wonder if Dan has some ideas about that?

Canne I hope you get this message before going to the boat!

[Canne]

No problem, I wanted to check again something since I will not see my boat and its instruments for a while:
I can confirm that the O v5.0.0+9065270 built-in dashboard's wind history and barometer history windows at startup do not behave like Tactics_pi's history windows: no matter is the the instrument USB cable plugged in or not at the startup of O, the history windows of built-in dashboard can be moved around easily even when no data is coming in. Also, the CPU load remains low.
So it is probably something with Tactics_pi's forked dashboard code base.