expereimental changes to connection edit dialog

[wholybee]

Some ideas related to issue #3700
#3700 (comment)

Everything I have done should be considered experimental just to see some ideas. The networking code in AdapterInfo.cpp is pretty rough and targets windows, so that should be completely rewritten.

[bdbcat]

Wholybee...
As you see, there are some build problems on linux and Mac.
I have looked at some of those. Mainly concerning "call by reference" problems, easily fixed.
I'll merge and do that tonight, unless you have a chance to correct the code beforehand.

[Hakansv]

gui/include/gui/connection_edit.h:154: trailing whitespace.
+
gui/src/AdapterInfo.cpp:71: trailing whitespace.

• if (count != 4) {
  

gui/src/AdapterInfo.cpp:73: trailing whitespace.

•     return 0;
  

gui/src/connection_edit.cpp:407: trailing whitespace.
+
gui/src/connection_edit.cpp:417: trailing whitespace.
+
gui/src/connection_edit.cpp:444: trailing whitespace.
+
gui/src/connection_edit.cpp:508: trailing whitespace.
+
gui/src/connection_edit.cpp:552: trailing whitespace.
+
gui/src/connection_edit.cpp:567: trailing whitespace.
+
gui/src/connection_edit.cpp:609: trailing whitespace.
+
gui/src/connection_edit.cpp:666: trailing whitespace.
+
gui/src/connection_edit.cpp:726: trailing whitespace.
+
gui/src/connection_edit.cpp:896: trailing whitespace.
+
gui/src/connection_edit.cpp:1172: trailing whitespace.
+
gui/src/connection_edit.cpp:1178: trailing whitespace.
+
gui/src/connection_edit.cpp:1362: trailing whitespace.
+
gui/src/connection_edit.cpp:1470: trailing whitespace.
+
gui/src/connection_edit.cpp:1914: trailing whitespace.
+
gui/src/connection_edit.cpp:1916: trailing whitespace.
+

[bdbcat]

Whollybee...
Merged and corrected small build problems.
Overall, looks great. A real improvement in UX. Thanks.
I see two small issues:

1. Did we not agree that network UDP must support TX or RX, but not both? This needs fixing.
2. On Network, "Use GRMN mode for input" is not valid. This mode can only apply to serial N0183 connections.

Thanks again.

[Hakansv]

I have a small question. This q instead of deeper own investigation:
This:

 //  For small displays, skip the "More" text.
 if (g_Platform->getDisplaySize().x < 80 * GetCharWidth()) MORE = "";

Does it mean small screen can't use filters and others normally hidden behind "More"?

[bdbcat]

Hmmm...
Good question. OP answer?

[Hakansv]

Another Q
Check UDP Multicast.
Address suggested then become 224.0.2.21.
I don't understand. What's that?

[wholybee]

Thank you for working on this while I was still at work. I lifted the More/Less implementation from where it was used in the plugin manager. Perhaps hiding it for a small screen isn't a good idea here. 224.0.2.21is suggested for a multicast IP address because it is valid and has not been registered for another service. If you use a normal IP address when trying to do multicast, it won't work, so a valid multicast address is suggested/filled. Simply checking multicast on both the Transmitting PC and every Receive PC and it will work without changing the IP from suggested, making it easy to setup for someone not familiar. Nohal and others suggested that the UI should be silent on Multicast, with no checkbox and no IP address hints. I am OK with that, but simply included it here as an example how it could work. I am happy to remove it. From: bdbcat ***@***.***> Sent: Friday, April 19, 2024 7:29 PM To: OpenCPN/OpenCPN ***@***.***> Cc: Warren Holybee ***@***.***>; Author ***@***.***> Subject: Re: [OpenCPN/OpenCPN] expereimental changes to connection edit dialog (PR #3798) Hmmm... Good question. OP answer? - Reply to this email directly, view it on GitHub<#3798 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIOGONP6UYDCBY34FBLY7ATY6HHFZAVCNFSM6AAAAABF5334H2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGUYTQNZRGA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[bdbcat]

Lets remove the small screen limitation, and we will see how it lays out on Android phones.
I do not yet have Android ready for O59, but coming soon.

I think the multicast flag is a good idea, in the "more" section. Let's keep it.

[Hakansv]

Sorry I didn't followed that discussion in all details but have tried to use it here.

My experiences:
Using UDP and 224.0.2.21 are not seen by others unless also that IP address is used on the receiver.
Using an address as "usual", 192.168.1.255 or 192.168.x.255 or even 224.x.x.255, are seen by all others. That is of course if others use input UDP 0.0.0.0 or localhost and the same port. This works for OCPN and other receivers like SignalK.

So the address 224.0.2.21 used on both tx and rx is when one for any (strange?) reason want to send only to designated receivers using the same address. And for performance use UDP instead of TCP.
To help first time users to set up a UDP transmit it may have been an alternative to use 224.x.x.255 instead of 224.0.2.21 and let all receivers use localhost or our default 0.0.0.0?
But there could be things I don't understand?

[Hakansv]

One comment if more input to this.
For a Signal K connection we may hide the "more" - "less" buttons. It's nothing there, see pict.

btw: The SK detection is not functional what I see. Neither with Auto detection enabled or not. I'm on Windows and checked for mdns in Wireshark while using the "Discover now". No Q Signlak activity.

[nohal]

Automatic server discovery has to be removed, does nothing.

[bdbcat]

Wholybee...
Are you planning to work these issues, or shall I? I worry about code collisions...

[wholybee]

Yes, i will work on them today. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: bdbcat ***@***.***> Sent: Saturday, April 20, 2024 7:15:07 AM To: OpenCPN/OpenCPN ***@***.***> Cc: Warren Holybee ***@***.***>; Author ***@***.***> Subject: Re: [OpenCPN/OpenCPN] expereimental changes to connection edit dialog (PR #3798) Wholybee... Are you planning to work these issues, or shall I? I worry about code collisions... — Reply to this email directly, view it on GitHub<#3798 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIOGONNU5XSYEADYX5MQUKTY6JZ6XAVCNFSM6AAAAABF5334H2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGY4DOMBZHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[wholybee]

The confusion is why others were opposed to having a multicast checkbox, it confuses people that don't know what it is. If you use a "normal" IP address and change the last octet to 255, you create a broadcast address. The UDP datagrams go to every device on the network, whether they want them or not. That is why the receiver can use 0.0.0.0, because it's going to get the datagrams regardless. The downside, consider a 48 port switch, only 4 devices wanting the UDP broadcast. And maybe its 4k video. And worse, maybe 4 other devices want a different 4k video. Now, you have 2 simultaneous 4k video streams going to everyone of the 48 ports. The switch gets hammered, and maybe things start to break. To address that, a block of ip addresses have been set aside as multicast. There is some behind the scenes activity going on. If multicast is used, the receiver sends a subscription to the switch. That tells the switch "i want traffic destined for this multicast address" Now, the switch knows not to send those datagrams to every port, but only those with subscriptions. An IP address ending in 255 becomes a broadcast address, again going to every port. Multicast only works with the group of IP addresses set aside for it. If you use an address out of that group, the subscription won't work. Further, many of those addresses have been assigned to specific protocols. So, i picked an IP address that was both in the multicast group, and not assigned to something else. It's an advanced feature, one that was suggested to not have a checkbox for, because it works fine if you enter a correct address without the checkbox, and an advanced user should know that. All the checkbox does is fill in a working address. Also, there was a version of this that looked at the users network configuration, got the users IP address (example 192.168.1.35) and then filled in 192.168.1.255 for output, and 0.0.0.0 for receive (if multicast was NOT) checked. But it was platform dependent and only worked on windows, so had to be removed. So, that's the reasoning. Happy to take it out. With low bandwidth data and a small network on a boat, probably there is no reason to have multicast support at all. Get Outlook for Android<https://aka.ms/AAb9ysg>

[Hakansv]

re:

With low bandwidth data and a small network on a boat, probably there is no reason to have multicast support at all.

Something like that was about to be my comment on this. Thanks.

[wholybee]

More reveals the Auth Token. Should the Auth token always be visible? Or should it move to below the more/less?

[Hakansv]

I've no clear view. That Auth token is seldom used so may confuse if not inside "more".
@nohal may have a clearer view?

[wholybee]

I think it should be moved to below the more/less. That would make it clear it is a lesser used field. Also, the more/less wouldn’t move up and down when clicked. @github.cosdf

[wholybee]

@BDCat If network is selected, does the “Use GRMN mode for input” need to be cleared as well as hidden? That is, if the button is checked on a serial connection, and then the user changes the connection to Network, will the hidden but still checked button cause an issue?

[wholybee]

Pull request created: Remove small screen limitation, allow more/less to work on Android. Remove GRMN mode checkbox from network connections. Remove SignalK server discovery controls. When selecting UDP, if both Input and Output are checked, uncheck output. Do not allow both Input/Output at same time. Move AuthToken field to bottom of form so it is more obvious that is what is being reveled when more is selected. Hide the Multicast checkbox. All the code is still there, however, just the checkbox is hidden by commenting out a few lines. There is one minor conflict, but I am not yet experienced enough with Github to know what to do with it.

[rgleason]

@bdbcat
From wholybee

@BDCat If network is selected, does the “Use GRMN mode for input” need to be cleared as well as hidden? That is, if the button is checked on a serial connection, and then the user changes the connection to Network, will the hidden but still checked button cause an issue?

[bdbcat]

While “Use GRMN mode for input” is a per-connection parameter, it is completely ignored for network connections.
So, no problem.