I dunno if this is appropriate for this community, so mods, please delete if not.

I have been writing a screen clone in rust.

https://github.com/cameroncros/PoorMansScreen/tree/better_screen (The main branch is how I currently use it, not at all screen-like, the better_screen branch is much closer to a screen replacement.)

It all currently works fine, albeit quite simple, and I suspect not following best practices. Please talk shit about my code so I can fix that :D

For my next stage of development, I would like to use some combo of vt100 and ratatui to wrap the shell in a border, or add a menu bar at the top or bottom to make it clear when the user is inside a “screen”. Does anyone have any thoughts on how to go about doing that? I am very unskilled at ratatui.

  • dangling_cat@lemmy.blahaj.zone
    9·
    3 days ago

    Screen is actually way more powerful than just opening a persistent session on the server side. It’s a terminal multiplexer, and you can use it to manage not only normal tty, but also USB serial! By replacing screen are you also going to recreate all the options like baud rate and /dev/ttyUSB0?

    • CameronDev@programming.devOP
      71·
      3 days ago

      Yeah, its a bit of a mess, it does so much. The thing I wanted was just the persistent sessions, so probably not gonna go further than that. Of course, the code exists, and someone else is welcome to take it and run with it (I’ll give it a permissive licence eventually).

  • livingcoder@programming.dev
    91·
    3 days ago

    I don’t know anything about screen. I think it would be great if you included a nice README.md file in the root of your repo for explaining what screen is and what your repo does both differently and the same. Please let me know if you do that. I’ll come and check out the repo at that point - kinda hard for me to want to jump directly into the code at the moment.

    • CameronDev@programming.devOP
      7·
      3 days ago

      I had thought screen was pretty commonly known, but its a tool you can use to background and reconnect to a process, with the child process being completely separated from your shell. So you can ssh into a box, start a process with screen, and then logout, return later and reconnect. (It also does other stuff like read from serial consoles)

      Codewise, there isnt a lot there, 3 main files (main.rs, server.rs and client.rs) all weighing in at ~200 lines.

      It felt premature to add a readme at this stagr, as I dont see this as a complete thing yet, but I can add a readme later today.

    • some_guy@lemmy.sdf.org
      21·
      2 days ago

      If you’re someone who might use this tool, you’re likely on a system that can run man screen. I agree that readme-s are useful. But just run man screen, find out what the tool is, be done. Otherwise, I think you’re asking the creator to do more work while I suspect you aren’t the target audience.

      • livingcoder@programming.dev
        1·
        2 days ago

        That’s an interesting take. I didn’t know that the tool screen even existed, so I had no idea that it would be nice to have in my toolbelt for future needs. A README also helps those that may already know a lot about screen and want to know the differences between screen and their implementation.

        There is nothing better in open source than a thorough, well-written README at the root of the project. Wanting others who don’t understand the source of the inspiration to be completely clueless is unfriendly (at best).

        • some_guy@lemmy.sdf.org
          1·
          2 days ago

          I’m pointing out that there is information available without asking the creator to explain it rather than suggesting that a readme shouldn’t be created. In software development, one of the primary skills is knowing where to find information yourself before interrupting others. I’m not suggesting that one shouldn’t ask for help; quite the opposite. I’m just trying to provide an answer as a third-party who is not in a position to author a readme. I don’t consider that unfriendly.

    • CameronDev@programming.devOP
      3·
      2 days ago

      The name of the branch is probably misleading, its not gonna be better than screen, it was meant to be better than my first attempt.

      This is likely to never have any real use outside of my own personal usage.

  • BB_C@programming.dev
    71·
    3 days ago

    If you’re serious about creating something good/better, you should use alacritty_terminal (not to be confused with the terminal app built on top of it) for low-level (from your PoV) terminal support.

    This is something zellij didn’t do. And now they have “basic functionality” bugs like this one open for years.

    I also wonder what made you pick screen as a baseline to improve on instead of tmux.

    • CameronDev@programming.devOP
      6·
      3 days ago

      I’ll look into that, I’m currently just using cross term, which was enough to pass my rudimentary tests of nyancat. I’ll have to create some form of test suite to chuck various inputs at it and confirm it all works correctly.

      Its definitely not intended to replace screen or be better, that would require a lot more features and work that I just dont want to do. Its for fun/scratching an itch.

      I started it originally when I had issues with screen and permissions issues. The main branch is what I actually use, and I use it for running Minecraft servers. Its just an easy way to send commands to stdin of the process. (Stdout connected to regular stdout, stdin connected directly to a Unix socket).

      As for tmux, most I’m not that familiar with it, and used screen more.

    • XTL@sopuli.xyz
      1·
      2 days ago

      My first thoughts was also “Don’t. Clone tmux instead.” But don’t use ctrl-b. It’s a massively awkward and annoying combo on common keyboards. And don’t make it necessary to release ctrl before the second key.

      • BB_C@programming.dev
        2·
        2 days ago

        But don’t use ctrl-b

        What migrant from screen didn’t start by adding this to tmux config? 😄

        set-option -g prefix C-a
unbind-key "C-b"
bind-key "C-a" send-prefix
    • CameronDev@programming.devOP
      2·
      2 days ago

      Well, your point stands regarding alacritty_terminal, but right now, it actually works just fine for that test case:

      I suspect once I stop directing the raw input/output to the shell, it might become more important.