Looking for feedback on this changed patch. Had to make the QNetAccessManager a little more accessible since it was only in main. I'm obviously not as good at Qt as you are...so hopefully this is better. I chatted a bit on the IRC channel for the balloon people and they thought the grid-change idea should work. I also have contacted r...@habhub.org to get feedback too. Who is Mal? They did say any unregistered call would not get reported so there would be little-to-no load on the SNUS server for this since grid changes never occur (as of yet that I've ever seen). So only balloon payloads should cause WSJT-X to report. If rovers start using JT modes that might change in the future but I've not seen any yet. Even then that would be low traffic.
RRR Mike W9MDB On Tue, Jan 5, 2016 at 4:55 PM, Bill Somerville <g4...@classdesign.com> wrote: > On 05/01/2016 20:29, Black Michael wrote: > > Here's a patch that adds this reporting. Pretty straight forward. I > > don't have any way to test this for real since there are no balloons > > in the area. > > I borrowed the reporting code from http://picospace.net/?p=552 > > > > The idea here is that if any grid change is detected it gets > > reported. I've never seen anybody doing JT65/JT9 mobile yet and since > > it's only enabled in the config it should work. > > First report will be ignored, all subsequent will get reported once a > > grid change occurs. > > > > I didn't restrict it to just JT9/WSPR either. Not sure we need to > > since only a grid change triggers it. > > Hi Mike, > > a few comments on your patch: > > It is better in include only the Qt headers for the classes you use. The > generic headers like QNetwork pull in a lot of unnecessary stuff that > slows down compilation. The only exception to that is probably code that > builds UIs where lots of widgets and friends are used. Even then I > usually pare down to the used classes only. > > There is no need to instantiate a QNetworkAccessManager, WSJT-X has one > already which you should use for adding requests. The QNAM interface is > designed so that many different network requests can be routed through a > single instance. This is important because it holds a lot of resources > including enough threads to service up to 6 concurrent requests. > > Where is the code for the slot MainWindow::onRequestCompleted ? It is > essential that the slot connected to the finished signal calls > deleteLater on the replies it handles otherwise there is a memory leak. > > It is better to use the new QObject::connect syntax that uses pointers > to member functions as it does type checking at compile time and would > in this case pick up the missing slot function at compile time rather > than at run time. > > Overall, I think we should wait on a response from Mal as to whether > messages to the SNUS server should be filtered. > > 73 > Bill > G4WJS. > > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
