Re: [wsjt-devel] Contest mode CQVHF

[Eric Gruff]

George,

Not necessarily. If you call CQ in contest mode, and I answer expecting a 
"normal" QSO, I may give up when I get "NC6K KF2T FMxx". Or, I send "KF2T NC6K 
-3" and you send "NC6K KF2T R FMxx", and I'm ticked off b/c I didn't get a 
report. 

There are several permutations where it would just be simplest to force the 
responding station into the same mode. It won't help people answering a contest 
station who want their signal report, but at least it won't drive everyone 
crazy.

73 de NC6K

-Original Message-
From: George J Molnar  
Sent: Tuesday, July 24, 2018 9:59 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Contest mode CQVHF

Wouldn’t it be simpler to have the sequencer logic respond to R XX## without 
choking? If we can do away with antipodal grids, that should make both modes 
compatible. The sequences will continue and not be lengthened by either or both 
of the operators trying to switch.

George J Molnar 
Virginia, USA


> On Jul 24, 2018, at 12:51 PM, Mark Spencer  wrote:
> 
> I'd support using an extra FT8 bit to explicitly indicate contest mode (using 
> another extra bit to explicitly indicate a "/R" call would also be nice.)   I 
> realize there is a desire to keep FT8 and MSK144 functionality as similar as 
> possible (and that MSK144 doesn't have the "extra bits" that FT8 has) but in 
> practice I don't believe MSK144 has nearly as many contest mode / vs non 
> contest mode issues.
> 
> 73
> 
> Mark Spencer
> VE7AFZ
> netsyn...@gmail.com
> 
> 
> 
>> On Jul 24, 2018, at 9:38 AM,   wrote:
>> 
>> I also was more than a bit frustrated with the contest mode this past 
>> weekend. It's not a fault of the software, just that there's no way to know 
>> from someone's CQ whether they are in contest or QSO mode.
>> 
>> A suggestion that is hopefully easy to code that might fix the problem - add 
>> a CQ predefined message that includes a binary flag to the software with 
>> 0=QSO mode and 1=contest mode. Then, when someone double-clicks on the CQ to 
>> respond, WSJT-X can switch to the appropriate mode. That will also help 
>> those of us in a contest that want to work non-contesters for points, even 
>> though those folks don't want to use contest mode.
>> 
>> 73,
>> 
>> Eric NC6K
>> 
>> -Original Message-
>> From: W0MU Mike Fatchett  
>> Sent: Monday, July 23, 2018 4:37 PM
>> To: wsjt-devel@lists.sourceforge.net
>> Subject: [wsjt-devel] Contest mode CQVHF
>> 
>> First of all I want to thank everyone for this great advancement in the 
>> hobby!
>> 
>> 
>> The CQ WW VHF was my first exposure to contest mode and it was a very 
>> frustrating 27 hours.
>> 
>> If I am in contest mode and I call CQ and get an answer from someone who 
>> is not, there is essentially no way to complete a qso unless one side 
>> changes into or out of contest mode.  What happened to me is I would 
>> switch and then the other side would switch and we would be opposite.  
>> Frustrating!
>> 
>> The main issue is that we cannot expect those not in the contest to have 
>> to switch into a specific mode to work us.  This does not happen in any 
>> other contest.  We cannot expect this from casual ops.  I am glad they 
>> want to work me.  Being able to work them should be painless too!
>> 
>> Why is contest mode needed?  If a qso is good in contest mode with less 
>> sequences I suggest that all FT8 exchanges be the same. Is there a 
>> specific reason two have multiple sets of exchanges for in a contest and 
>> not in a contest?  I don't think so.
>> 
>> I understand that this was an issue for the June VHF contest too.
>> 
>> If you guys can move my xmit around in fox/hound mode, which worked out 
>> really well, there has to be a solution for this.  I believe that the 
>> fox was still able to work people not running hound?  We need the same 
>> ability in contest mode.
>> 
>> I believe that this is already being examined but I thought I would give 
>> my feedback.  I would be happy to provide more information if desired.
>> 
>> Thanks again for all the hard work in bringing us FT8!
>> 
>> W0MU
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> --
> Check out the vibrant tech community 

Re: [wsjt-devel] Call 1st

[Eric Gruff]

Joe - I used it last night for quite a while on several HF bands, and it
worked very well. I didn't notice the Enable Tx button going off after the
end of the QSO, but don't mind it staying on. In any case, this is a welcome
and very useful feature - thanks!

Eric NC6K

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Monday, July 10, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Call 1st

Hi all,

I had not intended the "Weak" checkbox to be visible, just yet. Its function
is not yet implemented.

Code revision 7835 is yet another attempt to get the "Call 1st" logic just
right.  I think it should now do the following:

1. Decodes containing "MyCall" or falling within 10 Hz of RxFreq should
appear in the right window.

2. If "Auto Seq" and "Call 1st" are checked and you have transmitted a CQ
message, the first decode of someone calling you should behave as though you
have double-clicked it.

3. When your QSO finishes, another CQ transmission should be queued up, but
"Enable Tx" will be off.  To continue running a frequency you must click
"Enable Tx" again.

Please report any misbehavior of this feature!  We are getting close to a
v1.8-rc1 release.

-- Joe, K1JT


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Issue

[Eric Gruff]

Bill - good points, all. I wasn't advocating a situation where the response
to CQ is fully automated (robo-operator), but rather where (for example), I
see G4WJS working a station and realize I want to work you. I know you're
about finished with the previous QSO, so put my cursor on your DF and select
"Auto call to CQ/73" (or whatever we call it). Once the program decodes a
TX5 or TX6 with G4WJS as calling station, it sets TX1 and Enable Tx. So,
it's still me initiating the call, but the timing element is eliminated.
It's the same auto sequence in theory, but allows us to start the process
one step back, given the stringent timing requirements for FT8.

I must say that while my early use of the mode has me liking it, at least
half of the QSOs I've completed have an extra 30 seconds added to them
because I or the other station was a little slow to respond to the first CQ
and had to repeat the call. While K1JT has indicated that a partial decode
in excess of 50% of the period can theoretically be decoded, I am finding
(with very small N so far) that a late start is usually not decded. Given
the goal of taking advantage of short-duration openings, seems like saving
30 seconds could be make-or-break on VHF Es.

In any case, I'm excited to see how the mode works out when there's a freely
available version and we get a decent Es opening on 6 M.

73,

Eric NC6K


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, July 9, 2017 9:27 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 Issue

On 09/07/2017 17:16, Eric Gruff wrote:
> My suggestion was to enable a check box that auto sequences a call
(HISCALL MYCALL MYGRID) on the cursor frequency only if a CQ (TX6) is
selected. That way, you can park on his DF, and when he sends CQ, you will
automatically call him. I suppose we can get fancy and allow selection of
any CQ (including CQ DX) or just the standard one. It would also be nice to
have a check box that only calls another station after he sends 73- this
would be for when you want to work someone that is already in a QSO. If set
up this way, you won't QRM an ongoing QSO.

Hi Eric,

the model WSJT-X has always adhered to is that the user must initiate QSOs
and take action to progress QSOs. When fast modes were added it became
apparent that auto sequencing once a QSO has started was desirable, so the
requirement for user action to progress a QSO was relaxed. Imagine the
problems some are suffering with a 15s T/R period mode magnified when using
5s T/R periods in MSK144 or JT9(Fast). 
Although FT8 is technically a slow mode (message is not repeated during a
transmission), the 15s T/R periods make auto sequencing equally necessary.

So I would be surprised if further QSO automation were to be accepted by the
development team. I'm sure that Laurie VK3AMA or some other enterprising
developer will solve the problem of picking which caller to respond to by
scanning your station log using some user defined rules to pick the best
candidates in a fraction of a second after decodes occur. 
Even with JTAlert Laurie follows our lead in that you must start each QSO
yourself by clicking a button. You should have the final word on when you
call someone.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Issue

[Eric Gruff]

I thought about that, but how will it deal with two or more stations calling
right around the CQ DF?

 

From: George J Molnar [mailto:geo...@molnar.com] 
Sent: Sunday, July 9, 2017 9:29 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] FT8 Issue

 

Maybe a similar idea, but in reverse - when TX6 is selected and Enable TX is
True (you are calling CQ), any valid MYCALL HISCALL HISGRID response within
a certain DF range will get an auto response with TX2?

 

George J Molnar

Nevada, USA
KF2T  @GJMolnar

 

 

 





On Jul 9, 2017, at 9:16 AM, Eric Gruff mailto:egr...@cox.net> > wrote:

 

My suggestion was to enable a check box that auto sequences a call (HISCALL
MYCALL MYGRID) on the cursor frequency only if a CQ (TX6) is selected. That
way, you can park on his DF, and when he sends CQ, you will automatically
call him. I suppose we can get fancy and allow selection of any CQ
(including CQ DX) or just the standard one. It would also be nice to have a
check box that only calls another station after he sends 73- this would be
for when you want to work someone that is already in a QSO. If set up this
way, you won't QRM an ongoing QSO.



 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Issue

[Eric Gruff]

My suggestion was to enable a check box that auto sequences a call (HISCALL 
MYCALL MYGRID) on the cursor frequency only if a CQ (TX6) is selected. That 
way, you can park on his DF, and when he sends CQ, you will automatically call 
him. I suppose we can get fancy and allow selection of any CQ (including CQ DX) 
or just the standard one. It would also be nice to have a check box that only 
calls another station after he sends 73- this would be for when you want to 
work someone that is already in a QSO. If set up this way, you won't QRM an 
ongoing QSO.

Eric NC6K

-Original Message-
From: George J Molnar [mailto:geo...@molnar.com] 
Sent: Sunday, July 9, 2017 7:23 AM
To: Ed Wilson ; WSJT software development 

Subject: Re: [wsjt-devel] FT8 Issue

Ed, I also see your issue about not being quick enough on the trigger to 
respond to a caller on the first cycle. It does appear the window of 
opportunity is pretty small. Given the protocol, I’m not sure about the answer. 
Maybe extend the cycles to 20 seconds without increasing the TX time? Hire 
teenage gamers with cat-like reflexes to click for us old coots?

George J Molnar, KF2T 
Nevada, USA




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Testing

[Eric Gruff]

David,

I just swung the beam your way. If you're still around, I'm monitoring 14074
FT8.

Eric NC6K

-Original Message-
From: David [mailto:djm...@bigpond.com] 
Sent: Friday, July 7, 2017 8:19 PM
To: 'WSJT software development' 
Subject: [wsjt-devel] FT8 Testing

Hi All...been on 20m 17.074 calling CQ..Gary AG0N called me decode was
-19 but the band here is up and down at the moment .tnx Gary hope we can
do it sometime

73 David VK4BDJ



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8: IMPORTANT NOTICE

[Eric Gruff]

My thanks also to Joe and the team. Two QSOs completed so far, and one with
signal levels around -18. No repeats needed, and seems like all working so
far.


NC6K

-Original Message-
From: Dan Malcolm [mailto:dan.malcol...@gmail.com] 
Sent: Friday, July 7, 2017 5:42 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] FT8: IMPORTANT NOTICE

Thanks Joe.  I know you and your fellow developers have been hard at it, and
we appreciate the effort, and the great results.

One issue I am seeing that during a QSO, my QSO partners replies show up in
Band Activity fine, but get doubled in Rx Frequency.  I have screen shots,
and will provide them if you need them.  Thanks again.

Dan - K4SHQ

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: Friday, July 07, 2017 6:54 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] FT8: IMPORTANT NOTICE

To:  Users of FT8
From:WSJT Development Team
Subject: IMPORTANT NOTICE ABOUT FT8

If you are building WSJT-X for yourself from source code, you may now
upgrade to r7812 and recompile. You will then have access to the latest
version of FT8 plus some new features for setting default operating
frequencies by mode and IARU region.  The program built in this way will be
called WSJT-X v1.7.1 r7812.

Note that essentially the same program will soon be packaged for wider
distribution as as "WSJT-X Version 1.8.0-rc1" (release candidate 1), see
below).

Remember that FT8 in code revisions 7812 are higher is NOT COMPATIBLE with
that in 7782 and earlier.  To use FT8 you must upgrade to r7812.
If you see FT8 signals that do not decode, they may be using the obsolete
protocol.

About the Default Working Frequencies
=

FT8 will likely be popular with MF and HF users as well as the VHF multi-hop
sporadic-E DXers it was designed for.  After consultation with the user
community, we have reworked the suggested operating frequency defaults to
include FT8.  This was not easy on every relevant band; where possible, we
have suggested a 2 kHz range for exclusive FT8 use. 
(Exclusivity is important, as the T/R period is 15 s which will not mix well
with mode that use one-minute sequences.)

In general the FT8 frequencies are set 2kHz below the current JT65
allocation.  This should allow operation using a normal SSB filter width
without too much interference from strong JT65 signals up the band.  On some
bands that has not been possible since JT65 sits at the lowest usable narrow
band data mode frequency, when considering all international band plans.

For the 660 m and 2200 m  bands we have not assigned separate frequencies
for JT65/JT9/FT8, and just expect users to coordinate themselves.  The
numbers of active operators will probably be low enough that this will not
cause issues.

For 160 m we assume that the JT65 and JT9 sub-bands can be squeezed to
1 kHz each, and FT8 can sit above using up to another 1 kHz.

Previous 80 m use of JT modes has done a disservice to JA operators, who
have no privileges on the current WSPR/JT65/JT9 allocations.  To correct
this we have moved the allocations to a part of the band where JAs can
operate.  Obviously this change will impact other non-WSJT-X users, so for
now we suggest that if you intend to operate on 80 m JT65/JT9/WSPR then you
manually change the working frequencies in WSJT-X
("Settings->Frequencies") back to the old allocations until a general
availability release of WSJT-X v1.8.0 is published. This will allow time for
other software teams to coordinate with us.

The old allocations are:

JT65 3.567 MHz
JT9  3.578 MHz
WSPR 3.5926 MHz

For 6 m we understand that the IARU Region 1 band plan is not to the liking
of DX chasers around the world and largely ignored by Region 1 users.
However we cannot reasonably continue to set working frequency suggestions
that drive traffic to parts of the band that are not supposed to be used for
narrow band data modes.  The v1.8.0 release will allow Region-specific
working frequencies as well as globally coordinated ones.  Consequently we
have set the Region 1 working frequencies roughly in line with the band
plan.  If you do not like the allocations then do not complain to us, but
complain to your Region 1 band coordinator along with reasons why you think
it should change.  The proposed Region 1 working frequencies are usable
globally wherever 6m data mode operation is permitted so we have set them as
global rather than Region 1 specific.  Region 2 and 3 operators will have
both local and global frequencies offered.

Other changes are in line with current usage.


Finally, if you are waiting for pre-built installation packages:

We plan to post a release candidate for WSJT-X v1.8.0-rc1 configured for
Windows, Linux, and OS X very soon -- probably early next week.  Thanks for
your patience!

 -- 73, Joe, K1JT (for the WSJT Development Team)


--
Check o

Re: [wsjt-devel] FT8 Feature Request

[Eric Gruff]

I had a similar suggestion: Have a check box to enable auto sequence
response to a CQ within n Hz of the cursor frequency. If the message isn't
CQ, the program can disregard it to prevent QRMing an in-process QSO
(perhaps where one station needs a repeat). I often put the cursor on a QSO
with a station I want to work, and wait for the 73 to send my call and grid.
If this could be enable automatically, that would prevent the first response
from not decoding (I also have issues with this).

It would also be good to enable this for stations responding to a CQ,
although not sure how it would work if two stations responded on very close
DFs.

Eric NC6K 

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Monday, July 3, 2017 4:59 PM
To: 'WSJT software development' 
Subject: [wsjt-devel] FT8 Feature Request

Hi Joe, All,

After a brief stint in calling CQ, I soon realized my reflexes with the ole
mouse buttons are not what they used to be. I guess I've not been
participating in enough RTTY contests :-) In any case:

When in RUN mode (calling CQ):
- Would it be possible to assign a single hot-key to grab the First-In
Response to a CQ ?
- Additionally, what about a combination of First-In-First-Out /
Last-In-First-Out check boxes that grabs a response off the stack?
- Maybe an ESM (Enter Sends Message / Right Click ) sends the message from
the Band / Rx Frequency grids
- Lastly, maybe a way to quickly enable / disable ( just in the Band
Activity / Rx Activity) only the responses that contain MY_CALL

As this is a fast mode with HF contest potential, the items above are well
received in the RTTY community in several major programs. 

I'm finding it difficult to focus on the RX box for responses, click on the
responder, and not grab the wrong call, a;; within a second or so. I could
only imagine how that would be after 24hrs of contesting. I've miss-fired on
this several times already. It could be just me, and I've not been operating
fast modes for a while. 

Anyways, just a few thoughts to ponder.

73's
Greg, KI7MT



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK Usage and Policy Guidelines

[Eric Gruff]

Thanks, Greg. I think we all agree that we don't want to see the beta
updates no longer made available.

May I suggest to all the group users that if we see folks requesting install
packages, we offer to help them set up the JTSDK environment on their
machines, in the "teach a man to fish" spirit. They can then easily build
the releases by typing the few magic phrases "build-hamlib3" and
"build-wsjtx package". If they aren't willing, then they can wait for the
official release. Those that are really motivated to get on FT8 will have to
put out the relatively minimal effort.

I had a few minor issues because I didn't follow directions, then started
the install again, and it was very easy. I am happy to help if anyone needs
it. I know some of you are Linux and Mac expert users, so I think we will
have it covered. 

73,

Eric NC6K

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Sunday, July 2, 2017 3:47 PM
To: 'WSJT software development' ; 'WSJT
Group' 
Subject: [wsjt-devel] JTSDK Usage and Policy Guidelines

Hello All,

Appropriate Use
==

JTSDK exists to help users build and "test" Joe's software, not distribute
it.  We all want these fantastic applications, but, we "users" must respect
the developers requests.

I've received several reports of WSJTX packages built with JTSDK being
distributed by end-users. If this continues, I'll have no choice but to
remove the package build feature from JTSDK. Joe has, on many occasions,
requested that package installers not be re-distributed by anyone other than
the development team. Please respect their wishes!


For "Non-Developers" / "Testers" - (Setup && Usage)
===
For those of you "testing" Joe's software, a few things to note:

* DO NOT distribute the packages you build for yourself! < nuff said >
* Make sure, "before posting bugs", you are running the latest SVN revision
* Setup JTSDK-QT as follows:

- Open JTSDK-QT [1]
- Set the following options; can be on one line separated by a " ; "
semicolon,
or you can set them individually. If individually, you do not need the " ; "
:

enable-separate ; disable-quiet ; disable-skipsvn ; enable-autosvn ;
enable-clean ; enable-rcfg ; enable-qt55

You can, if desired, enable-autorun, which will launch the newly built
version for you.

* Check your options are set properly with [2]:   list-options
* Close, then reopen JTSDK-QT
* Build Hamlib3:  build-hamlib3
* Build the Release Install target (unless otherwise directed by a developer
for troubleshooting): 

build-wsjtx rinstall

You can build WSJT-X as often as you like, and should do; especially when
new features have been added, or the development team is requesting broader
use testing.

* Build an installable package ( DO NO DISTRIBUTE THESE < nuff said again >
):
* For most users, this is "not needed, nor desired for testing"

build-wsjtx package


Problems with JTSDK
=

If you have problems with JTSDK (not WSJT-X), email me off line, and we'll
get it sorted out.

@ ki...@yahoo.com
@ ki7m...@gmail.com

Or, post a bug on GitHub: 

Linux: https://github.com/KI7MT/jtsdk-nix/issues
Windows: https://github.com/KI7MT/jtsdk-win/issues


Documentation
=

For Windows, documentation is available online at:
http://jtsdk-win.readthedocs.io/en/latest/

For Linux:   /usr/share/doc/jtsdk/

If you find bugs in the Docs, report them to the appropriate GitHub location
above.


73's
Greg, KI7MT

[1] main-menu.png
[2] options.png




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Missing menu bar

[Eric Gruff]

Thanks, Joe. That did the trick.

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Saturday, July 1, 2017 1:44 PM
To: WSJT software development ; Eric Gruff 

Subject: Re: [wsjt-devel] Missing menu bar



On 7/1/2017 4:37 PM, Eric Gruff wrote:
> Minor finding in 7769 – when I uncheck and recheck the “Menus” box, 
> the WSJT-X window jumps to the upper left corner of the screen. It’s 
> reproducible on my Windows 10 install.  Otherwise, working great, and 
> seems signal reports are more in line with visual assessment of signals.
> 
> Eric NC6K

Position the window(s) where you want them, both with and without the new boxes 
checked.  Then they will stay where you placed them.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Missing menu bar

[Eric Gruff]

Minor finding in 7769 – when I uncheck and recheck the “Menus” box, the WSJT-X 
window jumps to the upper left corner of the screen. It’s reproducible on my 
Windows 10 install.  Otherwise, working great, and seems signal reports are 
more in line with visual assessment of signals.

 

Eric NC6K

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Saturday, July 1, 2017 12:58 PM
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Missing menu bar

 

I like the checkboxes...much more visible/intuitive,   May as well drop the 
CTRL-M too.

 

de Mike W9MDB

 

  _  

From: Joe Taylor mailto:j...@princeton.edu> >
To: wsjt-devel@lists.sourceforge.net   
Sent: Saturday, July 1, 2017 2:17 PM
Subject: [wsjt-devel] Missing menu bar

 

Hi all,

 

Far too many unwary users are being bitten by the "CTRL+M" bug.  In 

general, it seems like bad policy to hide screen controls and leave no 

visible way to get them back.

 

In r7769 I added a checkbox labeled "Menus" on the main window, and one 

labeled "Controls" on the Wide Graph.  These do essentially what CTRL+M 

does.  For now I left the oprion to use CTRL+M in place, but it should 

probably be removed.

 

There may well be better ways to place and/or configure the new 

checkboxes.  Please feel free to suggest changes.

 

-- Joe

 

--

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___

wsjt-devel mailing list

wsjt-devel@lists.sourceforge.net  

https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel