GNOME Bugzilla – Bug 103770
Last modified: 2021-06-10 12:45:23 UTC
In GNOME-Mud, we have the following dilemma:
We want to get rid our incomplete, buggy terminal handling code and have a
terminal library like vte handle all of it.
For a mud client, Gtk+'s split screen feature is also very attractive, so
we now have to chose between our crappy terminal support or no split screen.
It'd be nice if vte could have similar stuff as Gtk2's text widget, that
allows a terminal to be split in multiple ways.
It wouldn't be useful just for us. Others have pointed out that it'd be
very nice to have this in Gnome-Terminal itself too.
Is there a reason you can't just use two widgets? To split the screen
properly for applications, the widget would need to control and
respond to two pseudo-terminals, which would complicate the internals
The point of this request is to use two viewports of the same data,
not two distinct terminals.
The idea is that gnome-mud's user presses Page Up, and his GnomeMud
terminal splits: the upper one holds frozen past text (so he can check
how he killed a monster, or what was said by someone) while the lower
part of the screen still is in motion, getting the normal input from
the game. This is common in advanced MUD clients. I could attach some
screenshot of a client that supports this, if you wish, but I hope you
get the idea.
This would be a nice feature to have also in IRC clients, and even
regular terminals. Imagine scrolling up your terminal to locate some
documentation that's scrolled and being able to see the command line you
That requires a model/view split in vte first, but such an split will greatly help to do all kind of cool stuff, like his other request: display-independent persistent terminals, that you can detach from and attach to later (like screen does, but at gnome-terminal/vte level.)
I looked into this a bit tonight. Doesn't look bad at all. All we need to do is:
- Make VteTerminal not subclass GtkWidget. Add a VteTerminalView object that subclasses GtkWidget and references a VteTerminal.
- Move the font stuff, scroll_delta, and invalidated region stuff into View.
Then the terminal simply needs to dispatch a few things to views connected to it:
The view, depending on its mode (readonly or readwrite) sends back keystrokes and mouse events to the Terminal.
Not sure I'll code it all, but I'm playing with it right now.
This of course breaks API very harshly. One way to avoid that is to make VteTerminal actually subclass VteTerminalView. So the first terminal you make has a default view. Additional views can be created separately.
Communication between view and terminal can be done using signals, but I'm more inclined to open-code it instead. Not sure.
krh has a use case for using VteTerminal with non-gtk views. The split should accommodate that. In fact, maybe we should split into vte and vte-gtk. A vte-cairo view is also possible. It will push all updates to a cairo_t directly. Things to keep in mind.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/728.