After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 103770 - Model/view split
Model/view split
Product: vte
Classification: Core
Component: general
Other other
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks: 331621 vte1.0
Reported: 2003-01-17 19:52 UTC by Jordi Mallach
Modified: 2021-06-10 12:45 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Description Jordi Mallach 2003-01-17 19:52:20 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.
Comment 1 Nalin Dahyabhai 2003-01-17 19:58:52 UTC
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
Comment 2 Jordi Mallach 2003-01-30 23:06:27 UTC
Hi Nalin,
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.
Comment 3 Abigail Brady 2003-01-30 23:11:08 UTC
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
are editing...
Comment 4 Behdad Esfahbod 2006-04-20 14:06:57 UTC
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.)
Comment 5 Behdad Esfahbod 2008-11-24 03:38:46 UTC
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:

  - invalidate_cells

  - invalidate_all

  - scroll_to_cursor

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.
Comment 6 Behdad Esfahbod 2008-11-24 19:39:39 UTC
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.
Comment 7 GNOME Infrastructure Team 2021-06-10 12:45:23 UTC
-- 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: