It's hard to review the contents of Band Activity when busy by scrolling back, as each new decode forces the pane to scroll to the latest line. Could you update the widget code to only scroll when it's already at the end of the list?

It's hard to review the contents of Band Activity when busy by scrolling back, as each new decode forces the pane to scroll to the latest line. Could you update the widget code to only scroll when it's already at the end of the list?

James,
Have tried option in Settings > General Display are 'Start new period decodes at top'? It may be close what you want to achieve.
73, Reino OH3mA

Something like that has been asked before.

You're much better off if you use a companion program like JTAlert which gives you complete control over what you see.

Mike W9MDB

Hi Reino,
Yes, I tried that, if anything it's even less useful - but it does show that there is already some explicit scrollback manipulation going on in the code.

cheers - James

Yes, I tried that, if anything it's even less useful - but it does show that there is already some explicit scrollback manipulation going on in the code.

Hi James
How the presentation of the first decodes is less useful for you?
Back to your original question "Could you update the widget code to only scroll when it's already at the end of the list?" Do you mean by that by other words e.g. "present decoded lines only once all of those are decoded so that the last one is at the bottom of the display?" In that scenario you will lose main benefits of the new early decoding functionality. Perhaps only the "Call 1st" functionality will be useful.
Or do you mean that the Band activity window is first filled until it is full and then rest of the decoded are kept hidden until the very last one is available and in that moment the display is scrolled down to show the latest decodes?
In the latter case the scrolling, especially in a slow computer, will other happen on a busy band only after a new time period is already started and perhaps your transmitter is already active.

As Mike proposed that kind of decoded messages manipulation is best done in a companion program and the manipulation settings are done in there not in the basic WSJT-X. WSJT-X is basically performing the most critical job of decoding and provides only basic tools for QSO support.

73, Reino OH3mA

I understand the request in the OP differently than the other respondents apparently do. I take "review the contents of Band Activity" to refer, not to seeing the whole list of the most recent cycle's decodes, but to looking back through some number of cycles' worth of decodes, without the list constantly jumping to the most recent decodes every 15 seconds. James, is this what you mean? If so, I have often wished for the same function. If you turn off monitoring so you can scroll back and review like this, then you lose the incoming decodes during the period of non-monitoring. The function that I'd find useful is one that continues to accumulate incoming decodes in memory but does not post them to the screen until the user "releases" them.

I'm not sure what the most effective user interface for a function like this would be. James suggests not updating the decodes list unless the list is scrolled down to the bottom (or top, if that setting is selected). So the trigger for suspending the posting of new decodes would be the condition in which the last line decoded is not displayed on the screen (if I'm thinking straight).

The trigger for releasing the new decodes that have been accumulated without posting them might be trickier. Maybe the best way would be to let the incoming decodes accumulate as lines to be displayed (not just held in memory, to be displayed later, as I suggested above); the difference while in this "suspended" mode would be only that the list would not scroll to keep the most recent decodes in view. Then when the user is finished reviewing, he or she can just move back to the most recent decodes by whatever means they wish.

If anything like this were to be implemented, I would hope that it would be made a user-selectable option, in order to keep users who are familiar with the program's current behavior and unaware of this new function from thinking that something odd is happening.

Randy, WS4C

I guess the question in the OP can be understood either way (referring to reviewing one cycle's worth of decodes or browsing back through a number of cycles). The functionality James seeks would seem to apply equally to either scenario.

Randy, WS4C

I guess the question in the OP can be understood either way (referring to reviewing one cycle's worth of decodes or browsing back through a number of cycles). The functionality James seeks would seem to apply equally to either scenario.

Thanks Randy,
I seem to understand the need. In my mind all that is better to implement outside the WSJT-X itself also in future as it would make the UI more complicated. WSJT-X provides the decoded messages to be used by other programs as soon as those are decoded. On the other hand all decoded messages are also written in to the ALL.txt file (if user chooses so in 2.6.0 version) and there are already methods to study the "last lines". I don't recall who provided that for us.
Well, this is only my personal opinion or 2 cents.
73, Reino OH3mA

Yes, this is the behavior I think he is wanting... And I second it! Every time I try to look at something that has scrolled off the screen by more than a few seconds, it does not give me time to look at it before it goes away...

Turning off monitor will stop scrolling

sent by ve3wej on lg phone

On Thu., Oct. 13, 2022, 3:34 p.m. jamesraykenney, <jamesraykenney@...>
wrote:

Yes, this is the behavior I think he is wanting... And I second it! Every
time I try to look at something that has scrolled off the screen by more
than a few seconds, it does not give me time to look at it before it goes
away...

On Thu, Oct 13, 2022 at 03:36 PM, Dave Garber wrote:

Turning off monitor will stop scrolling

I mentioned this fact in my post. The downside of this is that you lose the incoming decodes while monitoring is off. For some people, that's no problem at all; others may want to keep their data stream more complete. Sometimes a juicy catch kind of lurks without transmitting much, and some ops would prefer not to lose these decodes, since those stations will often reply when called.

Randy, WS4C

I just scroll back up and don't release the mouse and till I find the
decode I was looking for... or just USE a bigger monitor....and open up the
window larger....

W1ZZ

--
tia
73
W1ZZ

On Thu, Oct 13, 2022 at 09:54 PM, Ed Stratton wrote:

I just scroll back up and don't release the mouse and till I find the
decode I was looking for... or just USE a bigger monitor....and open up the
window larger....

But what if you're not looking for a particular decode? Say you went to the kitchen to fix a sandwich, or you needed to take a phone call, and you just want to browse back through what you missed. Or say your system scrolls the window too fast to read while you're holding the mouse button down. Then what? Neither of those solutions will help in cases like this.

Randy, WS4C

On Oct 13, 2022, at 13:34, jamesraykenney <jamesraykenney@...> wrote:

Yes, this is the behavior I think he is wanting... And I second it! Every time I try to look at something that has scrolled off the screen by more than a few seconds, it does not give me time to look at it before it goes away…

The only practical way is to stop decoding. I do it frequently. Slow readers (me) will constantly be falling behind on a busy band, so I just stop it, knowing I will lose any incoming while stopped (so what?). It leads to lots less pressure. To make it so you can just keep going slower than the incoming will require a constantly enlarging buffer being built, and you reading old information that will probably be of no use. As previously mentioned, an outboard program will do what you want and not affect the way X works.

It just isn’t practical.

Gary - AG0N