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. 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. 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. 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 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 > ------------------------------------------------------------------------------ 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
