On 17/03/2015 12:13, Michael Black wrote:
Hi Mike,
I have had numerous instances of having to send 73 more than once when
I get a 2^nd RRR for example due to QRM or whatever. A small delay
(probably 3 seconds or so) would be better but would still prevent
queuing up another 73 in that case.
The Enable is turned off when 73 starts now…and while it's off if you
click TX 5 it switches to TX 6. So the switch occurs while you are
transmitting too apparently. That was the case I was referring to.
OK, I see what you mean now. I have refined the special treatment of 73
messages so that only the first one in a QSO causes the CQ message to be
queued up next. If your QSO partner repeats an RRR message after you
have sent a 73 message I suggest you simply double click the RRR message
to send 73 again. The second 73 message will now not queue up the CQ
message and neither will it trigger the log QSO dialog.
Give it a try and see if that helps with your use cases.
I was thinking this might be enough of a change that the checkbox
would be an obvious thing people would notice that would make them
read the balloon popup to see what it's for. Otherwise a lot of
people are going to be surprised and not know why TX 6 is being selected.
I was also thinking another way to educate users would be to change
the Enable button to yellow/orange/cyan (some other color) indicating
a special action is ready and the only thing you have to
click….another way to notify people that things have changed. So you
either click it or it turns back to gray at the next minute. When
changed to yellow the balloon would say "CQ is ready to be enabled".
Of course clicking off TX 6 would also turn it grey again. I think a
lot of people will double-click the RRR and not notice the CQ has been
set up for the next cycle.
Hmmm, that rather diverges from the accepted UI guidelines for checkable
buttons i.e. bi-state rather than tri-state.
Just throwing out some ideas before we start getting questions about
the new behavior…you know they aren't going to read and/or remember
the release notes.
I think the new behavior is great…but I was trying to think like a new
user and what would be "smooth" behavior in the corner cases.
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:[email protected]]
*Sent:* Tuesday, March 17, 2015 6:11 AM
*To:* WSJT software development
*Subject:* Re: [wsjt-devel] Tx 6 auto select
On 17/03/2015 04:10, Michael Black wrote:
Hi Mike,
I'd like to suggest that the Tx 6 auto select after 73 not be done
if Enable is not on.
It's a bit disconcerting to click Tx 5 after the minute has
started and see the TX 6 get selected immediately. Makes sense
if Enable is on given the new behavior…but not if it's turned off.
Just to clarify, under what circumstances would selecting message 6
not be correct?
Your last statement isn't quite logical, the selection of message 6
doesn't happen until you click enable, so enable is turned on when it
happens. I can see that it might be a little disconcerting as it all
happens in an instant. Would adding a short delay before message 6 is
selected work better.
Matter of fact…I'm thinking perhaps a checkbox next to Tx 6 that is
"Enable CQ select after 73 – must click Enable too" or such. So that
action is only performed if you want it.
I don't think that will help as it is going to confuse more users that
it helps IMHO.
I know it doesn't make a practical difference but aesthetically having
an action performed that is illogical/unnecessary is what got me.
I don't see what is illogical or unnecessary here, the application is
only doing what we discussed. Am I missing some use case where you
want to send your 73 message more than once? I would have thought that
is rare enough to justify having to click two widgets ("73" or "Tx6"
then "Enable Tx") to make it happen.
Mike W9MDB
73
Bill
G4WJS.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
