Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • dailybuild_linux-x64
  • dailybuild_win32
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

window.c

Blame
    • Deucе's avatar
      20ef1db5
      Fix status bar issue when RIP changes the number of lines. · 20ef1db5
      Deucе authored
      RIP is currently the only thing that can change the number of lines
      in the terminal while connected.  This can actually result in there
      being more lines on the screen than the last set video mode supports.
      
      There's a "feature" in SyncTERM text modes (curses, ANSI, and Win32
      Console) where if the screen mode is "current", it uses the number
      of lines in the terminal, but if it's anything else, it forces the
      number of lines to the lines in the mode.
      
      This works great until RIP increases the number of lines beyond the
      number in the mode... when this happened, RIP would draw the status
      bar at the incorrect location on the screen.
      
      This change no longer sets the max rows in the terminal if the
      backend can set individual pixels (required for RIP).  Further, to
      avoid a delay before redrawing the status bar after RIP changes the
      number of rows, the reinit_screen() function now sets a global to
      indicate it was called, and the status bar will always redraw when
      it's enabled and the flag is true.
      
      This *may* be related to bug 140, but may not be.
      20ef1db5
      History
      Fix status bar issue when RIP changes the number of lines.
      Deucе authored
      RIP is currently the only thing that can change the number of lines
      in the terminal while connected.  This can actually result in there
      being more lines on the screen than the last set video mode supports.
      
      There's a "feature" in SyncTERM text modes (curses, ANSI, and Win32
      Console) where if the screen mode is "current", it uses the number
      of lines in the terminal, but if it's anything else, it forces the
      number of lines to the lines in the mode.
      
      This works great until RIP increases the number of lines beyond the
      number in the mode... when this happened, RIP would draw the status
      bar at the incorrect location on the screen.
      
      This change no longer sets the max rows in the terminal if the
      backend can set individual pixels (required for RIP).  Further, to
      avoid a delay before redrawing the status bar after RIP changes the
      number of rows, the reinit_screen() function now sets a global to
      indicate it was called, and the status bar will always redraw when
      it's enabled and the flag is true.
      
      This *may* be related to bug 140, but may not be.