gnome-terminal + GNU screen integration

There's a lot of room to integrate gnome-terminal and vte with GNU screen. In fact, proper integration if possible can deprecate a lot of code in vte (like the scrolling management.) However we are not sure we quite want do that, as screen may be buggy or lacking on certain systems, and we don't want to limit ourself to its limitations.

The following list enumerates some various levels that integration can be done. It's divided into explicit and implicit, where explicit means that the user knows about the screen session, while implicit means the screen session is set up and used internally as an implementation detail of the terminal widget, and is not immediately exposed to the user. The screen integration if done well, removes the need to implement a lot of new features in vte, like the model-view split.

• Explicit:
  • Have a menu of current screen sessions that choosing one will attach the terminal into it. Have options for doing a readonly attach. [easy]
  • Have an option to create a new terminal session inside a new screen session. [easy]
  • With both of above, of course, have the option to detach the terminal. [easy]
  • Make g-t show tabs for each screen "screen". [hard]
  • Make scroll bar work in an screen session. [hard]
  • Make screen's copy/paste work with the clipboard. [hard]
• Implicit:
  • Make (or have an option for) g-t to always start new sessions inside screen. [easy]
  • With the above, make terminal escape the screen escape sequence, such that it's transparent to the user. [easy]
  • Have an option to detach the terminal. [hard]
  • Make scroll bar work in an screen session. [hard]
  • Make screen's copy/paste work with the clipboard. [hard]
  • Add graphical widgets and keybindings to screen's backward search feature. Find a way to do the search incrementally (add feature to screen.) [hard]

Those marked hard basically need g-t to communicate with the screen program, and as far as I know screen doesn't have a library interface to allow that. The only way to communicate with it is to send escape sequences and parse the output (of say the list of current screens, or the clipboard.)

Bugs

https://bugzilla.gnome.org/show_bug.cgi?id=332148 Bug 332148 – Support for GNU screen

https://bugzilla.gnome.org/show_bug.cgi?id=103770 Bug 103770 – Want splitscreen feature as in Gtk's text widget

Discussion

(08:17:58 PM) Behdad Esfahbod: Kosai, Monia: I was thinking today, a great way to make the screen integration happen
(08:18:12 PM) Behdad Esfahbod: Kosai, Monia: is to develop screen to expose a library interface
(08:18:31 PM) Behdad Esfahbod: that should be /very/ easy, and makes all the hard items in my list very trivial
(08:21:42 PM) Kosai: Ooh.
(08:22:25 PM) Behdad Esfahbod: Kosai: so, you just call screen_session_show_screen_number (session, 4) to switch to the fourth tab :)
(08:22:46 PM) Behdad Esfahbod: which is just what the magic keybindings are doing right now
(08:23:00 PM) Behdad Esfahbod: nothing to implement in screen, just expose them.
(08:23:14 PM) Monia: right
(08:24:04 PM) Kosai: Woo.
(08:24:27 PM) Behdad Esfahbod: so we don't have to do any magic in vte/g-t to send control sequences to screen to change to another tab
(08:24:47 PM) Behdad Esfahbod: (which is possible in the case of tab switching, but not for copy/paste, search, ...)
(08:25:10 PM) Kosai: Yup.  Sounds perfect.
(08:25:17 PM) Behdad Esfahbod: in the long term, if that looks robust enough
(08:25:26 PM) Behdad Esfahbod: we can tear the scrolling support off vte
(08:25:52 PM) Behdad Esfahbod: and since screen allows for attaching to a session (readonly / readwrite), we get model/view separation for free
(08:26:04 PM) Kosai: And have a hard dep on screen?
(08:26:07 PM) Behdad Esfahbod: yeah
(08:26:13 PM) Kosai: Cool.
(08:26:13 PM) Behdad Esfahbod: that's for the long term
(08:26:50 PM) Behdad Esfahbod: screen is probably a lot smarter than g-t in handling odd sequences
(08:27:01 PM) Behdad Esfahbod: so we are just piggybacking on it
(08:28:43 PM) Kosai: Sounds like we get to ditch a lot of g-t code.
(08:30:03 PM) Behdad Esfahbod: not g-t really, vte mostly.
(08:30:17 PM) Behdad Esfahbod: kinda "use screen as a backend" feature in vte
(08:30:24 PM) Kosai: right.
(08:30:30 PM) Behdad Esfahbod: that's of course for the "implicit" part
(08:30:39 PM) Behdad Esfahbod: for explicit, we need some menus in g-t
(08:31:16 PM) Behdad Esfahbod: but if we go that route, then g-t doesn't really have to create new widgets for each tab
(08:31:21 PM) Behdad Esfahbod: and can use screen's tab support
(08:31:29 PM) Behdad Esfahbod: but that may not be feasible
(08:31:40 PM) Behdad Esfahbod: maybe as long as tabs are using the same profile
(08:32:14 PM) Behdad Esfahbod: or better yet, we can add the notion of tab into vte itself
(08:32:32 PM) Kosai: Yeah, gets confusing if the user has some local terminals (implicitly inside screen) and some remote ones inside a non-vte screen.
(08:32:57 PM) Behdad Esfahbod: yeah, got to decide what to do there
(08:34:55 PM) Behdad Esfahbod: in the mean time we can actually import our hacked screen in vte
(08:35:04 PM) Behdad Esfahbod: so, no dependency, no upgrades
(08:35:22 PM) Kosai: Hm.
(08:35:43 PM) Behdad Esfahbod: and when we are satisfied with the screen api, we can start pushing it upstream
(08:36:05 PM) Kosai: *nod*