On 22/05/2015 23:37, KI7MT wrote: Hi Greg & Joe, a few comments from me below:
> Hi Joe, > > I am not familiar HSHV, so I can't comment on it directly. However, I do > have a few comments that me be of some use while considering a new path(s). > > The major Debian based derivatives have already pushed past Qt5.2. Most > are on 5.3 and Ubuntu, for their next LTS release will be on 5.4 at > least. I am not sure about Mac, maybe Bill or John can provide more > information there. No doubt Richard can tell us about Fedora / RHEL > situation. Published builds on Mac are already using Qt 5.4, there are no problems with the WSJT-X code base with respect to this. I have not been treating this as an urgent issue on Linux and Windows since the majority of Linux users are still probably tied to distributions that use Qt 5.2. When I get some time I will upgrade my build VMs for Linux and Windows and check that we are Ok with Qt 5.4 for official releases, I'm not expecting any serious issues. I don;t think this is an urgent issue until we find some feature of Qt 5.4 that we would like to use. > > It would seem to me that, keeping as many of the applications on the > same tool chain / IDE framework as possible would make things much > easier for the Core Developers (yourself, Bill, Steve, John, etc), those > testing the various apps, and maintainers trying to package them into > their respective *Nix distribution. I know for me personally, this would > make things much easier. Christo has done a great job with the MSHV application and it is definitely worth investing more effort into, we must respect the work he and others have put into it so I would rather find a way of collaborating rather than forking his source code. We surely can help with moving to Qt 5 and hopefully Qt multimedia so the application is more portable across platforms, also unified building and packaging across all the platforms is, I believe, an area where MSHV could benefit from collaboration with the WSJT-X team. > > As far as Static Linking goes, that is a big problem for *Nix > maintainers. It is a battle most of cannot win for production packaging. Agreed and it is a clear violation of third party GPL components licensing conditions. > > I would think, starting off with source code close to what you want is > the ideal situation, then again, if you must re-work the majority of > code, it may be faster to go the other way. > > It would be sad to see WSJT development retire and move to a different > project, as that is where it all began to so to speak. Maybe a > collaborative effort, or joining of teams would make sense ? > > No matter which way you decide to go, I am sure the community will > support it in whatever capacity they can. > > > best regards, > > Greg, KI7MT 73 Bill G4WJS. > > > On 05/22/2015 02:51 PM, Joe Taylor wrote: >> Hi all, >> >> I have some further thoughts on topics raised in my message earlier today. >> >> As I stated there, the planned incorporation of all WSJT "slow modes" >> (JT4, JT9, JT65, and WSPR) in WSJT-X is nearing completion. >> >> Some time ago we noted that the usage and program behavior in the WSJT >> "fast modes" (FSK441, JT6M, JTMS, and ISCAT) are sufficiently different >> from the slow modes that it seems best to isolate them in separate >> programs. Doing this would leave WSJT-X and MAP65 as the only active >> branches in our present SVN repository. In practice this means >> primarily WSJT-X, since I regard MAP65 as essentially "complete" and in >> need only of occasional maintenance updates. >> >> A Qt-based program supporting the fast modes would then be required, to >> replace the current Python-based WSJT10. I had imagined that this might >> be a next major project to tackle, from scratch... but in fact this may >> not be necessary. >> >> Christo Hristov, LZ2HV, has already built a WSJT fast-modes program. He >> calls it "MSHV", and it looks very good. It has all the WSJT fast modes >> and essentially all the fast-mode features, with some evident >> improvements. Its user interface is all new (but has essentially the >> same look and feel as WSJT). Its encoders and decoders are direct >> translations from WSJT's Fortran into C++. >> >> In short, to me it no longer seems worthwhile to think of starting a new >> WSJT-fast-modes program. Instead, we could use one of these options, or >> some combination of both: >> >> 1. We could simply direct WSJT fast-mode users to Christo's program, >> perhaps posting links to it on the WSJT web site. >> >> ... and/or ... >> >> 2. We could start with his source code, but build our own executables >> from it -- no doubt modifying it in some ways, probably minor at first. >> In this case we would give Christo (and his collaborators) full credit >> for their work. (It is licensed under GPL v3.0 -- as it must be, since >> it's ultimately based on WSJT.) >> >> I haven't tried compiling Christo's program yet. As you'll see on his >> SourceForge web page, https://sourceforge.net/projects/mshv/ -- see also >> http://lz2hv.org/mshv -- he builds with Qt 4.8.6, MinGW, and gcc 4.9.2, >> and he statically links everything(!). So compiling with our standard >> tool set will take a bit a bit of effort, at first. But I imagine that >> it would be not too difficult to transition his code to our set of build >> tools and our manner of packaging, if we choose to do that. >> >> Christo posts installable packages for Windows XP/7 and for 32- and >> 64-bit Linux. The packaging uses a rather different approach than ours, >> and perhaps has some licensing issues. >> >> I would be interested in the views of others in our development group! >> >> -- Joe, K1JT ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
