Add next-gen terminal mockups, targeting Tilix

These are my mockups of a next-gen terminal emulator, originally published on Mastodon to illustrate my thoughts about what I'd like to see terminal emulators implement (in a nutshell, better integration between the shell & the native UI). Since GNOME Terminal is reluctant to implement newer interface paradigms, and since I use Tilix anyway (for that very reason), they "target" Tilix.

The original Mastodon thread is reproduced below:

What I would really like to see is more integration between terminal emulator and the shell (and commands you run in it). Currently in Fedora/GNOME the shell prompt is set up to make the terminal notify you (with a native GUI notification) about long running commands completing. That's cool, but we could go so much further.

For one, the shell could let the terminal know the current directory, hostname, username, git branch, current command, last command status, etc. etc.

The terminal then would display that info in its GUI, and perhaps even let you interact with it (imagine a GtkPopover for changing git branches and a Nautilus-like pathbar for the cwd!) We could then shrink back the prompt back to a simple dollar sign.

That would already be infinitely cool, but it gets better.

What if the shell could send its completions to the terminal and the terminal would display them in a native autocomplete widget (like in Builder)?

What if the terminal could track where the output of each command is and allow you to collapse/expand it with a GtkExpander? What if it could visually present each command and its output as this expandable card, along with the time it was issued and the time it took to run (like time outputs) and its exist code? And if it failed, paint that card red? And if it segfaulted, add a button to duck duck go the error, run ABRT or even run dnf debuginfo-install and coredumpctl gdb?

What if pagers like less could make use of the native scrolling instead of faking it by moving lines? What if man rendered the content to HTML (or GTK's native markup format) and presented it as an actual page, sort of like what you get by running yelp man:foo but right there in the terminal?

What if ls could make use of the native list/table widget and render file icons, just like Nautilus? What if you could expand the folders it outputs right there using mouse and get a tree view?

Don't tell me that fish or vim already display completions in a pop-up using some magical pseudographics. I'm not talking about abusing the old grid-of-characters model of terminals. I'm talking about making the shell and the terminal communicate better so we can use native (e.g. GTK+) widgets for what is traditionally done using text-based interfaces.

Mind, just like currently ls knows to columnize and colorize its output and grep knows to highlight the matches in red when outputting to a terminal, but fall back to plain text when piped to something, what I'm describing here would simply fall back to plain text when piped or run in a less magical terminal. So this is about enhancing the existing tools, not about breaking compatibility in any way.

And at the same time that would really get the terminal/shell experience from "emulating ancient hardware to be able to do stuff we haven't yet made a GUI for" to "a way to do advanced stuff with your computer using a command-based interface".

That would truly be a command-based interface for the 21th century. That would be something I'd be proud, not ashamed, to show off to Windows users as the advanced way to tune your system.

---

I've made a mock-up to illustrate my ideas about the next-gen terminal experience!

Featuring:

• the pathbar
• username, hostname and git branch displayed in the UI, shrinking the shell prompt back to just a $
• commands as cards
• syntax highlighting, including graying out the output a bit to differentiate it from commands themselves
• autocompletion (displayed in a native widget)
• built-in error handling options
• the time each command took (on the right)

All the widgets are interactive! You can click on the pathbar to cd, and the popovers on the bottom bar let you basically do ssh, su and git checkout; the git one additionally allows you to open the current repo in Gitg or in Builder.

---

Since everyone seemed to love my terminal mockups, I've made another one!

This is a further design exploration, showcasing:

• background jobs label/popover
• ls displaying an actual list of files! Of course, they are interactive, you can drag'n'drop them from here, click them to open, and right-click for more options.
• autosuggestions being contextual: here, they suggest you to re-run apt as root or read the docs
• a collapsed card
• git using real graphics

(end Mastodon thread quote!)

Some clarifications:

• This MR is purely about graphic design, the implementation is a whole other question for another time.
• The mockups have received overwhelmingly positive feedback on Mastodon, though there was also some criticism.
  • It was @bertob who saw them on Mastodon and asked me to make this MR! He also suggested I label the mockups Tilix.
• The idea of shell integration is not new or unrealistic, other terminal emulators (iTerm2, Extraterm, etc) implement this already, although they don't (yet) utilize it to this extent.
• There is prior art; in particular, see Upterm (née Black Screen) and TermKit, both abandoned, both implementing their own shells rather than integrating with bash (and both not native enough for my taste):
• I'm sadly not a designer, so my mockups are imperfect. Do iterate on them! Here are some topics to consider:
  • Is it OK to gray out the output of commands? That gives the text a nice structure, but perhaps it's achievable in a different way? Should we gray out the commands themselves instead? What is more important, the commands or their output?
  • Could we visually differentiate stdout from stderr?
  • Do we actually want to always show time for each command? Perhaps only on hover?
  • Where do we put all the other info about a command/card? (the time it was started, cwd/hostname/username at the time, git branch name, git commit hash, the three numbers time outputs, anything else?) In a popover? How does the user open it, should there be a three-dots menu icon somewhere?
  • How do we visually indicate the change of cwd/hostname/username/branch done from an interactive UI element? Do we insert a special mini-card ("now running as root")? Do we just paste and run the real command (su)? Or maybe we just do nothing?
  • Should the expander go to the right side? Is it OK that it's only shown when a card is collapsed? Could we integrate the expander with the prompt (perhaps changing the prompt to a ▶ instead of a $)?
  • Where do we put Tilix's "fork this view" buttons? I feel that putting them on the left side would push the pathbar to the right too much, and putting them on the right makes it five buttons in a row, which doesn't look that great.
  • What does the right-click menu allow you to do?
  • How does expanding folders in ls output work (from the design perspective)?
  • What does native-widget-based pager (less) look like? What does native-widget-based man look like (n-w-b pager plus native markup)? — think the man mode of yelp (GNOME Help), but still looking "like terminal".
• Unlike other mockups in this repo, these are not wireframes (...me not being a designer).
  • The way I made them is by building up the widgets part of the UI off real GTK widgets and rendering the contents of the terminal manually in GIMP.
  • I'm putting the widgets.ui Glade file and the two GIMP image files (plus their rendered PNG versions) along with a run.py script that loads the files and opens the window into the src/ folder. These are all extremely hackable.
  • Note: the only purpose of that Glade file is too look good in the screenshots. The buttons don't do anything. The pathbar is a single GtkLabel. Things are hardcoded. The labels of the radio buttons are whitespace-padded (yuck). I repeat, the only purpose of that Glade file is too look good in the screenshots.
  • Perhaps it makes sense to port this to Inkscape/wireframes? Perhaps not?

cc @bertob @YaLTeR @BrainBlasted @chpe @gnunn