Rethinking the need for CT compatible mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Rethinking the need for CT compatible mode

Nate Bargmann-4
I recently did a bit of fixup to the CT compatible mode but I find that
its original choice of keystrokes to not be optimal.  As I added support
for some keys used in N1MM+ when ESM is disabled, the code became even
more convoluted and opaque.

I realized that CT compatible mode had been broken for so long that
there really must not be anyone using it, so why keep it?

Removing it would simplify the code in several places.

In its place I would consider adding support for the apostrophe " ' " to
send the CQ_TU_MSG or S&P_TU_MSG.

I would consider providing a :CFG keyword or keystroke combination to
toggle Enter from ESM to a mode where with the call field empty Enter
sends MYCALL and otherwise would only log a QSO when both the call and
exchange fields are populated depending on validation.

Thoughts?

73, Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Csahok Zoltan
Hi Nate,

Personally I always use the default TLF mode and quite happy with it.
Removing CT compatibility is fine with me.
I didn't quite get the difference between the current and the optional new mode,
though. (I'm not a regular N1MM user)

73,
Zoli


On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:

> I recently did a bit of fixup to the CT compatible mode but I find that
> its original choice of keystrokes to not be optimal.  As I added support
> for some keys used in N1MM+ when ESM is disabled, the code became even
> more convoluted and opaque.
>
> I realized that CT compatible mode had been broken for so long that
> there really must not be anyone using it, so why keep it?
>
> Removing it would simplify the code in several places.
>
> In its place I would consider adding support for the apostrophe " ' " to
> send the CQ_TU_MSG or S&P_TU_MSG.
>
> I would consider providing a :CFG keyword or keystroke combination to
> toggle Enter from ESM to a mode where with the call field empty Enter
> sends MYCALL and otherwise would only log a QSO when both the call and
> exchange fields are populated depending on validation.
>
> Thoughts?
>
> 73, Nate
>

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Thomas Beierlein-4
Hi Nate and Zoli,

in last days I checked the mailing list archive and my personal
remarks. As far as I found Nate you were the first one to ask about
the CT mode compatibility in last 5 years.

So it seems that there is not so much interest in it.

From my point of view I am open for removal.

73, de Tom DL1JBE

Am Fri, 10 Jan 2020 10:39:54
+0100 schrieb Csahok Zoltan <[hidden email]>:

> Hi Nate,
>
> Personally I always use the default TLF mode and quite happy with it.
> Removing CT compatibility is fine with me.
> I didn't quite get the difference between the current and the
> optional new mode, though. (I'm not a regular N1MM user)
>
> 73,
> Zoli
>
>
> On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:
> > I recently did a bit of fixup to the CT compatible mode but I find
> > that its original choice of keystrokes to not be optimal.  As I
> > added support for some keys used in N1MM+ when ESM is disabled, the
> > code became even more convoluted and opaque.
> >
> > I realized that CT compatible mode had been broken for so long that
> > there really must not be anyone using it, so why keep it?
> >
> > Removing it would simplify the code in several places.
> >
> > In its place I would consider adding support for the apostrophe " '
> > " to send the CQ_TU_MSG or S&P_TU_MSG.
> >
> > I would consider providing a :CFG keyword or keystroke combination
> > to toggle Enter from ESM to a mode where with the call field empty
> > Enter sends MYCALL and otherwise would only log a QSO when both the
> > call and exchange fields are populated depending on validation.
> >
> > Thoughts?
> >
> > 73, Nate
> >  



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Fred Siegmund
I use it for the german XMAS contest. As this is a sprint, where you
have to leave QRG after CQ, I don't like ESM (and changing between CQ
and S&P all the time).

73 Fred

Am 12.01.20 um 19:48 schrieb Thomas Beierlein:

> Hi Nate and Zoli,
>
> in last days I checked the mailing list archive and my personal
> remarks. As far as I found Nate you were the first one to ask about
> the CT mode compatibility in last 5 years.
>
> So it seems that there is not so much interest in it.
>
>  From my point of view I am open for removal.
>
> 73, de Tom DL1JBE
>
> Am Fri, 10 Jan 2020 10:39:54
> +0100 schrieb Csahok Zoltan <[hidden email]>:
>
>> Hi Nate,
>>
>> Personally I always use the default TLF mode and quite happy with it.
>> Removing CT compatibility is fine with me.
>> I didn't quite get the difference between the current and the
>> optional new mode, though. (I'm not a regular N1MM user)
>>
>> 73,
>> Zoli
>>
>>
>> On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:
>>> I recently did a bit of fixup to the CT compatible mode but I find
>>> that its original choice of keystrokes to not be optimal.  As I
>>> added support for some keys used in N1MM+ when ESM is disabled, the
>>> code became even more convoluted and opaque.
>>>
>>> I realized that CT compatible mode had been broken for so long that
>>> there really must not be anyone using it, so why keep it?
>>>
>>> Removing it would simplify the code in several places.
>>>
>>> In its place I would consider adding support for the apostrophe " '
>>> " to send the CQ_TU_MSG or S&P_TU_MSG.
>>>
>>> I would consider providing a :CFG keyword or keystroke combination
>>> to toggle Enter from ESM to a mode where with the call field empty
>>> Enter sends MYCALL and otherwise would only log a QSO when both the
>>> call and exchange fields are populated depending on validation.
>>>
>>> Thoughts?
>>>
>>> 73, Nate
>>>    
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Nate Bargmann-4
* On 2020 12 Jan 16:17 -0600, Fred Siegmund wrote:
> I use it for the german XMAS contest. As this is a sprint, where you have to
> leave QRG after CQ, I don't like ESM (and changing between CQ and S&P all
> the time).

Hi Fred.

Do you use the + and Insert keys?  Their mapping was reversed from CT
for a long, long time and I switched their mapping in the Git master
branch (post 1.4.0).

Would the following from my OP meet your needs, particularly the action
of Enter?

> > > > In its place I would consider adding support for the apostrophe " ' "
> > > > to send the CQ_TU_MSG or S&P_TU_MSG.
> > > >
> > > > I would consider providing a :CFG keyword or keystroke combination
> > > > to toggle Enter from ESM to a mode where with the call field empty
> > > > Enter sends MYCALL and otherwise would only log a QSO when both the
> > > > call and exchange fields are populated depending on validation.

73, Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Thomas Beierlein-4
In reply to this post by Fred Siegmund
Hi Fred,

some time ago Ervin provided a SPRINTMODE keyword for that kind of
contests. Did you had a chance to check if it is what you need?

73, de Tom

Am Sun, 12
Jan 2020 23:14:36 +0100 schrieb Fred Siegmund <[hidden email]>:

> I use it for the german XMAS contest. As this is a sprint, where you
> have to leave QRG after CQ, I don't like ESM (and changing between CQ
> and S&P all the time).
>
> 73 Fred
>
> Am 12.01.20 um 19:48 schrieb Thomas Beierlein:
> > Hi Nate and Zoli,
> >
> > in last days I checked the mailing list archive and my personal
> > remarks. As far as I found Nate you were the first one to ask about
> > the CT mode compatibility in last 5 years.
> >
> > So it seems that there is not so much interest in it.
> >
> >  From my point of view I am open for removal.
> >
> > 73, de Tom DL1JBE
> >
> > Am Fri, 10 Jan 2020 10:39:54
> > +0100 schrieb Csahok Zoltan <[hidden email]>:
> >  
> >> Hi Nate,
> >>
> >> Personally I always use the default TLF mode and quite happy with
> >> it. Removing CT compatibility is fine with me.
> >> I didn't quite get the difference between the current and the
> >> optional new mode, though. (I'm not a regular N1MM user)
> >>
> >> 73,
> >> Zoli
> >>
> >>
> >> On Tue, Jan 07, 2020 at 08:27:55PM -0600, Nate Bargmann wrote:  
> >>> I recently did a bit of fixup to the CT compatible mode but I find
> >>> that its original choice of keystrokes to not be optimal.  As I
> >>> added support for some keys used in N1MM+ when ESM is disabled,
> >>> the code became even more convoluted and opaque.
> >>>
> >>> I realized that CT compatible mode had been broken for so long
> >>> that there really must not be anyone using it, so why keep it?
> >>>
> >>> Removing it would simplify the code in several places.
> >>>
> >>> In its place I would consider adding support for the apostrophe "
> >>> ' " to send the CQ_TU_MSG or S&P_TU_MSG.
> >>>
> >>> I would consider providing a :CFG keyword or keystroke combination
> >>> to toggle Enter from ESM to a mode where with the call field empty
> >>> Enter sends MYCALL and otherwise would only log a QSO when both
> >>> the call and exchange fields are populated depending on
> >>> validation.
> >>>
> >>> Thoughts?
> >>>
> >>> 73, Nate
> >>>      
> >
> >  



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Nate Bargmann-4
In reply to this post by Nate Bargmann-4
What's the thinking on this?  I'd like to simplify the code page and the
man page, if possible.

73, Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the need for CT compatible mode

Thomas Beierlein-4
Am Thu, 21 May 2020 07:19:00 -0500
schrieb Nate Bargmann <[hidden email]>:

> What's the thinking on this?  I'd like to simplify the code page and
> the man page, if possible.
>
> 73, Nate
>

Hi Nate,

thanks you brought it on the table again.

The last comments from Fred DH5FS questioned the use of the
Enter-send-message scheme for QSO input. Thinking about it we should
make sure that we can log a QSO via ESM and also without.

Correct me if I am wrong: Atm the only way is using ESM or working in
CT mode?

I for myself see no need to keep the CT mode but We should strongly
check that you can enter a QSO without ESM.

73, de Tom

--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


attachment0 (201 bytes) Download Attachment