" You are trying to force your view of usage which seems unreasonable given
there is a valid alternative."
I'm not trying to force anything. The user interface is misleading because of
the nomenclature that is used on the button, in the option, and in the tool
tips. The functionality is correctly described in the help file. It that is
considered satisfactory there is nothing more to be said.
73,
Andy k3wyc
________________________________
From: wsjt-devel-requ...@lists.sourceforge.net
<wsjt-devel-requ...@lists.sourceforge.net>
Sent: Monday, January 2, 2017 10:41 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 15
Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
wsjt-devel Info Page -
SourceForge<https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
lists.sourceforge.net
Your email address: Your name (optional): You may enter a privacy password
below. This provides only mild security, but should prevent others from messing
with ...
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net
You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:
1. Re: Disable Tx after RRR/73 (Bill Somerville)
2. Re: Disable Tx after RRR/73 (Black Michael)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Jan 2017 17:39:43 +0000
From: Bill Somerville <g4...@classdesign.com>
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID: <7843a265-ec44-83d5-5c15-a5559eaa0...@classdesign.com>
Content-Type: text/plain; charset="windows-1252"
Hi Andy,
comments in line below.
On 02/01/2017 17:22, ANDY DURBIN wrote:
>
> There was always a Halt TX button but, with the r3673 functionality of
> Enable TX, I don't think it was needed. Removing it would not be
> reversion.
>
The internal implementation is an auto transmit enable, having it also
halt transmit immediately has to be an add on to that. Having a halt tx
immediately avoids overloading the function of the buttons, that is a
good thing because it allows different operators to use the interface as
they wish. You are trying to force your view of usage which seems
unreasonable given there is a valid alternative. Client "Halt Tx" if you
want immediate stop and click "Enable Tx" if you wish to complete the
message that is currently running.
>
>
> The first step would be to understand why the change from "TX Enable"
> to "Next Enable" was made. I see no advantage but I only use JT9 and
> JT65 on HF and 6m. I assume there was some advantage in other
> operating environments.
>
No such change has happened. What has happened is that the overloaded
feature of having "Enable Tx" turn off auto transmission *and* having
"Enable Tx" stop immediately has been simplified - without any loss of
functionality *because the "Halt Tx" button already does the latter"*.
>
>
> If the arguments for the change are still valid then, obviously, it
> won't be changed back to the simple TX Enable that it used to be in
> r3673 and earlier. If that is the case then I hope the description
> inconsistencies that I listed earlier will be addressed.
>
The arguments were for simplification without loss of functionality. Joe
has already cited the documentation that clearly states the current
functionality is for "Enable Tx" OFF only disables auto transmit, it
does not discard the current message if transmission has started, "Halt
Tx" does that.
>
>
> Moving to brainstorming mode - The color red seems inappropriate for
> the indicator for either functionality. If tri-state is an option
> I'd suggest no fill for no TX possible (no change), Green for auto
> enable - this message and the next one will be sent, and Amber for
> this message is the last one that will be sent. Colors would change
> at the end of the TX period or when this button or Halt TX was pressed.
>
Statefull push buttons are generally considered as bad design, the other
button types like radio buttons and check boxes are designed for exactly
that purpose. Having said that most UI widget tool kits offer checkable
push buttons and they can be useful where they are used a lot and a
check box might be considered too small for quick operation. The
overriding design criteria should reflect the chosen button semantics
and in that respect we have it wrong as push button controls are meant
to mimic momentary push buttons that immediately start something. Going
to tri-state semantics is moving way too far from that behaviour IMHO.
73
Bill
G4WJS.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Mon, 2 Jan 2017 17:41:10 +0000 (UTC)
From: Black Michael <mdblac...@yahoo.com>
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Message-ID: <1760675014.5370778.1483378871...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
It was removed in 7442
de Mike W9MDB
From: Bill ND0B <n...@ockert.us>
To: 'WSJT software development' <wsjt-devel@lists.sourceforge.net>
Sent: Monday, January 2, 2017 11:17 AM
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
#yiv0617045516 #yiv0617045516 -- _filtered #yiv0617045516 {panose-1:2 4 5 3 5 4
6 3 2 4;} _filtered #yiv0617045516 {font-family:Calibri;panose-1:2 15 5 2 2 2 4
3 2 4;} _filtered #yiv0617045516 {panose-1:2 11 5 2 4 2 4 2 2 3;} _filtered
#yiv0617045516 {panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv0617045516 #yiv0617045516
p.yiv0617045516MsoNormal, #yiv0617045516 li.yiv0617045516MsoNormal,
#yiv0617045516 div.yiv0617045516MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0617045516 a:link,
#yiv0617045516 span.yiv0617045516MsoHyperlink
{color:blue;text-decoration:underline;}#yiv0617045516 a:visited, #yiv0617045516
span.yiv0617045516MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv0617045516
p.yiv0617045516msonormal0, #yiv0617045516 li.yiv0617045516msonormal0,
#yiv0617045516 div.yiv0617045516msonormal0
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0617045516
span.yiv0617045516EmailStyle19 {color:windowtext;}#yiv0617045516
.yiv0617045516MsoChpDefault {font-size:10.0pt;} _filtered #yiv0617045516
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv0617045516 div.yiv0617045516WordSection1
{}#yiv0617045516 Good morning, ?I just noticed this morning using r7441 that TX
Enable is disabled (and the log prompt pops up) at the start of a TX4
transmission.?? This is new behavior in one of the recent versions and I agree
with those asserting it appears to be in error.?? The contact can be considered
over when one of the stations RECEIVES RRR, not when one of the stations
transmits it. ?Enable Tx and Halt Tx appear to operate as they always have,
this is a change in how ?Disable TX after sending 73? is interpreted.?? I do
not believe it to be correct to interpret this as disabling TX after sending an
RRR.?? This does not make sense either semantically or operationally. ?73 de
Bill ND0B ? ?From: ANDY DURBIN [mailto:a.dur...@msn.com]
Sent: Monday, January 2, 2017 8:54 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Disable Tx after RRR/73 ?"I figured out my issue with
the auto sequencing stopping at RRR. It does not have anything to do with with
prompt to log pop up. I had Disable TX after sending 73 checkmarked in
Settings/General tab. For some reason, it is disabling TX after sending RRR
instead." ?You have been caught by what I think is a very misleading user
interface! ?In earlier versions of wsjt-x if "Enable TX" was not red you could
not transmit. ?The name was consistent with the behaviour. ?The function was
then changed to enable auto sequencing ?(or something similar). ?Now the Enable
TX light extinguishes at the start of 73 but the 73 continues to be sent. ?I
don't know why this behaviour was changed but I don't like it. ?The current
interface is misleading because several items were not changed to reflect the
new behaviour. ?? ?1. The button is still called "Enable TX" but TX is still
enabled when it is not lit2. The behaviour option is called "Disable TX after
sending 73" ?but this selection actually disables auto sequencing at start of
733. ?The tool tip for the behaviour option does not describe what the option
actually does4. The tool tip for the Enable Tx button does not describe what
the button/light does/indicates. ?Either the behaviour needs to be changed back
to how it used to be or the function names need to match what the system
actually does. ?My preference would be to go back to it being an Enable TX
function. ? If the Enable Tx?button really did what is was labeled as, ?there
would be no need for the Halt TX button. ?73,Andy k3wyc ? ? ? ? ?From:
wsjt-devel-requ...@lists.sourceforge.net
<wsjt-devel-requ...@lists.sourceforge.net>
Sent: Monday, January 2, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 9 ?Send wsjt-devel mailing list
submissions to
??????? wsjt-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
??????? https://lists.sourceforge.net/lists/listinfo/wsjt-devel
| wsjt-devel Info Page - SourceForgelists.sourceforge.netYour email address:
Your name (optional): You may enter a privacy password below. This provides
only mild security, but should prevent others from messing with ... |
or, via email, send a message with subject or body 'help' to
??????? wsjt-devel-requ...@lists.sourceforge.net
You can reach the person managing the list at
??????? wsjt-devel-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:
?? 1. Re: Prompt to log QSO when either RRR or 73 is sent (Jay Hainline)
?? 2. Re: Prompt to log QSO when either RRR or 73 is sent
????? (Bill Somerville)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Jan 2017 13:40:47 -0000
From: "Jay Hainline" <ka9...@mtcnow.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is
??????? sent
To: "'WSJT software development'" <wsjt-devel@lists.sourceforge.net>
Message-ID: <004801d264fd$d3a2c8d0$7ae85a70$@mtcnow.net>
Content-Type: text/plain; charset="utf-8"
I figured out my issue with the auto sequencing stopping at RRR. It does not
have anything to do with with prompt to log pop up. I had Disable TX after
sending 73 checkmarked in Settings/General tab. For some reason, it is
disabling TX after sending RRR instead.
?
?
73 Jay KA9CFD
?
From: Jay Hainline [mailto:ka9...@mtcnow.net]
Sent: January 1, 2017 22:08
To: 'Black Michael' <mdblac...@yahoo.com <mailto:mdblac...@yahoo.com> >; 'WSJT
software development' <wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net> >
Subject: RE: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
?
I don?t know for certain why this was changed in the first place except the
JT65 HF crowd is always looking for a way to sidestep a sequence to shorten the
time for a QSO. This does not work in the meteor scatter VHF world where you
are relying on random data bits to fly in on a meteor for less than 1 second
and you are trying to decode just what the guy on the other end has received.
If it aint broke, don?t fix it.
?
I hope I don?t get black balled for being negative like the Ham Radio Deluxe
people do to users of their software. Lol ;-)
?
73 Jay KA9CFD
?
From: Black Michael [ <mailto:mdblac...@yahoo.com> mailto:mdblac...@yahoo.com]
Sent: Sunday, January 1, 2017 3:39 PM
To: WSJT software development < <mailto:wsjt-devel@lists.sourceforge.net>
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
?
I think the consensus solution would be to make it a user option.
Seems the meteor scatter people have the most problems with it since they were
quick to speak up.
?
I had proposed at one time to make the "Prompt me to log QSO" a tri-state box
so one could check 73, 73+RRR, or none.? But seems the binary choice is clearer
and there are no other tri-state checkboxes in WSJT-X.
?
So this patch makes it optional with an added option line below the current
prompt option.? All worlds should be happy with this.
?
?<https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1>
https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1
?
?
de Mike W9MDB
?
?
? _____?
From: Seb < <mailto:w...@miamisky.com> w...@miamisky.com>
To: WSJT software development < <mailto:wsjt-devel@lists.sourceforge.net>
wsjt-devel@lists.sourceforge.net>
Sent: Sunday, January 1, 2017 1:26 PM
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
?
IMHO the introduction of the log QSO prompt when you are sending RRR does not
solve or help anything.?
?
It is useless when you are doing meteor scatter. If I?m sending Tx3 and the
other station hears that and sends Tx4 and then logs the contact, it is not a
valid QSO because I have no idea if the other station has heard my report.? I
will end up sending Tx3 several times until I just give up on the contact.
?
73 de Sebastian, W4AS
?
On Jan 1, 2017, at 9:38 AM, Jay Hainline < <mailto:ka9...@mtcnow.net>
ka9...@mtcnow.net> wrote:
?
This was introduced in r7431. I think its bad form to get a prompt to log the
QSO when you are sending RRR. How do you know if your QSO partner has received
it if he does not send 73 back to you??
?
Jay Hainline KA9CFD
Colchester, IL? EN40om
?
?
?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org!? <http://sdm.link/slashdot>
http://sdm.link/slashdot
?
_______________________________________________
wsjt-devel mailing list
?<mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net
?<https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
?
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Mon, 2 Jan 2017 13:53:41 +0000
From: Bill Somerville <g4...@classdesign.com>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is
??????? sent
To: wsjt-devel@lists.sourceforge.net
Message-ID: <88cd7f71-519d-d86e-abcd-b04edce31...@classdesign.com>
Content-Type: text/plain; charset="windows-1252"
On 02/01/2017 13:40, Jay Hainline wrote:
> I figured out my issue with the auto sequencing stopping at RRR. It
> does not have anything to do with with prompt to log pop up. I had
> Disable TX after sending 73 checkmarked in Settings/General tab. For
> some reason, it is disabling TX after sending RRR instead.
Hi Jay,
the disabling of auto Tx and the automatic pop up of the logging dialog
are currenty linked. I believe the thinking was that if you are able to
log then you should stop sending. IMHO this is only true for the caller
as the station running the frequency is obliged to keep sending RRR
until they are sure that the caller has seen it, even though their end
of the QSO is compete and they can log it. This made sense when the
logging reminder only came up for 73 messages, now it also does for RRR
messages and that is causing the problem here.
Maybe we should pop up the log QSO dialog but only disable auto Tx once
the Ok has been clicked. Another option might be to split the setting
into two options like "Prompt to Log QSO" and "Disable auto Tx *after*
logging", the latter maybe only applying if the message that prompted
logging was a 73 message.
There must be a way of doing this that satisfies all modes and operating
methods.
73 & HNY
Bill
G4WJS.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
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
End of wsjt-devel Digest, Vol 35, Issue 9
*****************************************
------------------------------------------------------------------------------
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
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
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
End of wsjt-devel Digest, Vol 35, Issue 15
******************************************
------------------------------------------------------------------------------
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
