Thanks, but my comment referred only to changes that impact users, not details behind the scenes - that would indeed be unnecessary.

I've looked at the link to the change log, but even that wasn't obvious to me what it is - it doesn't say change log in the filename, just wsjt-x xxx.log.  Then the change titles aren't exactly user friendly either!

For the bewildered non-programmer user perhaps trying to find out why something doesn't work any more, or has changed behaviour, it's almost impossible even if they did know where to look in the first place.

The issue reported here doesn't affect me, but my plea is simply for documentation to be clear, complete and intuitive as that's what seemed to me to be missing this case.  Programmers will of course know the detail, but users will not.

If there's detail that would be simply too much to document then simply include a statement about that as well, and for such changes in other libraries all that's needed is a simple link to their change logs, unless a change looks like it might result in significantly different behaviour within wsjt-x.

I'm not complaining, just trying to make already excellent software better by hopefully reducing support requests, by enabling users to more easily find stuff out for themselves. Keep up the good work.

Alan G0TLK

On 16/02/2021 11:16, Bill Somerville wrote:
Alan,

that is a completely unreasonable request, WSJT-X uses many supporting libraries and on some platforms the version used is dependent on the operating system version rather than what we specify. Nevertheless we do include a summary change history for both WSJT-X and Hamlib with every release.

For example review the change log for WSJT-X v2.3.0 which you can find here next to the release notes: https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/

Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e

and for change: 4faad82da727e908cfc79d856f391d9feed46e7e

to see the two changes related to this issue.

Note that a Hamlib developer made a change to fix an issue, we took that change on good faith. We also asked for an option to revert to the old behaviour for users that needed it. You would have us not take the fix for the problem so you can remain a Luddite, sorry that's not the way things work.

I have changed WSJT-X for the next release to override the Hamlib behaviour and enable PTT sharing for all users, that will mean that if the original problem is real then unsuspecting users will have problems even if they have no use or knowledge of PTT sharing between Hamlib clients. Let's see how that goes?

73
Bill
G4WJS.

On 16/02/2021 10:59, Alan Groups wrote:

And if I may chip in most importantly please make sure *all* changes are listed in release notes, with a link to release notes for libraries that are used - so users can see them intuitively.

Leaving users to find out about changes unexpectedly in what is becoming a large and complex app leads to unnecessary bug reports and frustration/irritation all round!

Alan G0TLK
On 16/02/2021 10:49, tom wrote:
Thanks for the update Bill

I have no issue with options being configurable but as Alex put it - ’never touch a running system’ - tidy up coding to make it more robust yes but removing a feature IMO is same as altering a default - it no longer works the same.

Also as with Alex just deleted a chuck of this reply so the thread does not go down hill fast.

Expressed my point I hope some more consideration may be given if this sort of issue arrises in the future.

Tom
GM8MJV

On 16 Feb 2021, at 10:32, Bill Somerville <g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:

Hi Alex and Tom,

the Hamlib change was not a change of defaults, it was a removal of a feature that apparently was causing issues. I asked that it not be removed and the option offered was to make it a configuration option.

73
Bill
G4WJS.

On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:

Totally in agree with Tom

I delete part of my previous email to avoid start arguments BUT in IT we always said “never touch a running system” and for programming also apply, why change the previous default for something doesn’t works? And create just problems?

PTT and associated routines was working great up to WSJT-X 2.2.2, why change that?, the proof of the pudding is in the eating, for sure exist a valid reason by “the authors” but unfortunate this time maybe wrong.

Alex, HB9DRI

*From:* tom <t...@tkrh.co.uk>
*Sent:* Tuesday, February 16, 2021 4:18 PM
*To:* Black Michael <mdblac...@yahoo.com>; WSJT software development <wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port

Hi All

Don’t want to start an argument and please feel free to ignore my comments.

It seems a LOT of the errors recently seem to be because HamLib have altered defaults and others have to pick up the flack.

It always used to be the case ’never alter the default’ - yes add new features but never change the default.

There has been the issue of powering rigs on - default changed, shared ptt - default changed.

There are more than a ‘couple of complains’ on this mailing list alone to keep the status quo.

Please Please Please DO NOT start to toss the blame around - oh it up to xyz to change their software to over-ride the changes we made.  Just keep defaults as they were and all will be happy.

End of rant

Tom

GM8MJV

    On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
    <wsjt-devel@lists.sourceforge.net
    <mailto:wsjt-devel@lists.sourceforge.net>> wrote:

    A couple of complaints from those who were using a single
    instance were having problems with the constant open/close of
    the serial port.

    So it was changed to support the simple case and those that
    want the more complex case of multiple apps have to use the
    additional file as WSJT-X authors have decided to not include
    any options in the rig control user interface.

    I'm looking at the sharing now to see if there is a problem
    going on.

    Mike W9MDB

    On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda,
    HB9DRI <hb9...@emeham.com <mailto:hb9...@emeham.com>> wrote:

    Hello Bill

    Following your instructions I use your file  (looks the same
    as I use before) and I place in the properly log directory for
    each of the WSJT-X (totally 4) and doesn’t work, the PTT is
    not share.

    I wonder why if in WSJT-X 2.2.2 the PTT com port was share by
    default now is not?

    Regards

    Alex, HB9DRI

    *From:*Bill Somerville <g4...@classdesign.com
    <mailto:g4...@classdesign.com>>
    *Sent:* Monday, February 15, 2021 6:29 PM
    *To:* wsjt-devel@lists.sourceforge.net
    <mailto:wsjt-devel@lists.sourceforge.net>
    *Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1
    COM port

    Hi Alex,

    try the attached file. It needs to go in the log files
    directory of each WSJT-X instance ("Settings->File->Open log
    directory").

    73
    Bill
    G4WJS.

    On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:

        Hello Mike

        Sorry I didn’t answer to the list;

        I create a file named hamlib_settings.json and paste
        inside the code you send me:

        {

         "config": {

        "ptt_share": 1

             }

        }

        Then placethis file in
        C:\Users\[username]\AppData\Local\WSJT-X and in

        Each of the 4 WSJT-X folders but doesn’t work,

        Alex, HB9DRI

        *From:*Black Michael via wsjt-devel
        <wsjt-devel@lists.sourceforge.net>
        <mailto:wsjt-devel@lists.sourceforge.net>
        *Sent:* Monday, February 15, 2021 11:11 AM
        *To:* wsjt-devel@lists.sourceforge.net
        <mailto:wsjt-devel@lists.sourceforge.net>
        *Cc:* Black Michael <mdblac...@yahoo.com>
        <mailto:mdblac...@yahoo.com>
        *Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and
        2.4rc1 COM port

        The PTT port is no longer shareable by default.

        Place this file in C:\Users\[username]\AppData\Local\WSJT-X

        {

         "config": {

        "ptt_share": 1

         }

        }

        Mike W9MDB

        On Sunday, February 14, 2021, 07:43:47 PM CST, Alex
        Artieda, HB9DRI <hb9...@emeham.com
        <mailto:hb9...@emeham.com>> wrote:

        Just to inform you, I found a bug regarding COM port for
        PTT, it appears in WSJT-X 2.3 and in 2.4 RC1, let me explain.

        I run 4 WSJT-X at the same time, I use Omnirig to control
        my IC9700 but PTT is manage via a COM port, this is a must
        for me to TX first a Sequencer via the COM port and later
        TX the radio, I cannot use CAT for PTT,  that guarantee me
        no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all
        configure to use COM3 for PTT, in this configuration I can
        TX with ANY of the 6 programs, more precise I can TX with
        the program were the decodes or best decode happens,
        unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with
        the FIRST program who opens the PTT COM port, the other
        ones don’t work and MAP65 give a opening COM port ERROR,
        the other WSJT-X simple don’t TX, would be great to fix
        this bug because when you run multiple WSJT-X is a must to
        work with all instance capable of TX, WSJT-X 2.2.2 works
        perfect.

        To confirm this bug I roll back to 2.2.2 and install 2.3
        and later 2.4RC1, the bug appear in 2.3

        73 de Alex, HB9DRI




_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to