Loading ...
Sorry, an error occurred while loading the content.
Skip to search.

1769Re: [V4Protocol] Re: V4 GUI improvement proposal

Expand Messages
  • Rick Westerfield
    Sep 6, 2011
      I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.

       I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.

      Many thanks. It really is good code in all other respects.

      Rick KH2DF

      Sent from my iPhone

      On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:


      Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

      73 Finn/LA7UM

      --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
      > Demetre,
      > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
      > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
      > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
      > The basic rule is simply this:
      > The ISS stays the ISS UNTIL:
      > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
      > AND
      > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
      > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
      > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
      > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
      > 73,
      > Rick KN6KB
      > .

    • Show all 30 messages in this topic