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 782576 - Set ws_xpixel and ws_ypixel
Set ws_xpixel and ws_ypixel
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-05-12 22:32 UTC by Egmont Koblinger
Modified: 2020-05-27 15:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2017-05-12 22:32:18 UTC
I've just realized that termios's struct winsize has, in addition to the two fields storing the number of cells, another two fields for the size in pixels. It is filled out by some terminal emulators. We could join them.

It's unclear to me what the intent and the exact semantics (see below) of this field. There's hardly any info I could find on the net.

One might argue that a client app running inside the terminal emulator should not be able to query this information, it's none of its business. However, we already break that by answering to the "\e[14t" sequence with the window size in pixels, plus we break these kinds of principles at other places too (e.g. focus in/out reporting).

This piece of information might become handy if we ever implement some kind of image rendering support. Being able to synchronously query these values is a huge aid for apps intending to leverage this feature, rather than having to expect an asychronous response to an escape sequence which is a real PITA.

Also, this gives us a convenient method of notifying apps about font size change: simply a SIGWINCH is sent to them. I've checked that the Linux kernel indeed sends this signal even if only the pixel size changes, and ssh also forwards this event.

---

To quickly query the values (e.g. to see if an emulator supports these), use either a "strace stty size", or this python snippet:

import array, fcntl, termios
buf = array.array('H', [0, 0, 0, 0])
fcntl.ioctl(1, termios.TIOCGWINSZ, buf)
print(buf)

Beware of the stupid output order: y x x y.

---

These variables are forwarded by ssh and screen, but are not forwarded to mc's subshell (I can fix it if it becomes important) or in tmux. Any other important software along these lines to test? [Actually screen and tmux probably won't be important... at least not until they also implement a VTE-compatible image support.]

xterm forgets to update these variables on font size change. (I'm lazy at the moment to figure out how to change the font size runtime in the other emulators.)

---

Here's a support matrix of some emulators.

"base" means that the reported numbers are the number of cells multiplied by each cell's size, "extended" means it also includes the standard padding (border), the extra padding in case the window size is not grid-aligned (e.g. maximized), and the scrollbar.

                \e[14t       ws_[xy]pixel
xterm            base(*)      extended
urxvt            extended     base
pterm (putty)    extended     base
st (suckless)    -            base
VTE              base         -
konsole          -            -
terminology      -            -

(*) Ctrl + right click -> Allow Window Ops

I especially "love" how xterm and urxvt are the exact opposite of each other :-)

On one hand, I don't see the point in reporting the "extended" size, _that_ (i.e. UI chrome) is really not the business of the client app. What if these emulators supported multiple tabs, would they also include the tab bar's size? What if they had CSD? ... Also, it's not helpful at all if we're about to use this feature for drawing pixel graphics.

On the other hand, what's the goal of this feature? If the goal would be to know the cell size, why not store that in the first place?

Probably noone knows, it's a legacy leftover that we might try to hijack for a certain purpose...
Comment 1 Egmont Koblinger 2017-05-13 08:03:23 UTC
... of course, this is another step away from the model/view separation :/
Comment 2 Christian Persch 2017-05-13 08:12:06 UTC
In the case of high-DPI, should this report physical or logical pixels? Both seem problematic, without a way for the app to determine the DPI value of the output.
Comment 3 Christian Persch 2017-05-13 08:13:53 UTC
...the DPI value of the output, or the scale factor.
Comment 4 Egmont Koblinger 2017-05-13 12:41:33 UTC
Excellent question, I don't know the answer. Probably either one is acceptable, just the image displaying code has to be in sync with it so that scaling is transparent to the client apps.

Pushing it even further: With UIs like cool-retro-term's, the concept of cell size doesn't even make sense...

Technically, we could just set these variables to the same values that we report for \e[14t right now. It's probably a small change, although provides no practical benefit at the moment :)

---

Maybe it's time to stop and look at the big picture and a vision where VTE is going.

There have been several attempts to adding graphics support in various terminal emulators, and none of them really took off. It probably boils down to a couple of factors: Technical difficulties that are hard (or almost impossible) to solve cleanly (e.g. font size; what to do on rewrap), lack of coordination among terminal emulators, lack of buy-in from key applications... maybe most importantly lack of user interest. How many apps are there out there which try to display graphics? w3m does it with some nasty X11 hacks, I've seen screenshots of Ranger (not sure if it does similar X11 hacks or if those were UI mockups only), and that's all I've seen. First, a web browser (and honestly, I use a real graphical web browser for surfing the net, only reaching out to text-based ones in really special circumstances where seeing pictures is the least I care about), and then a file manager (where previewing files is actually a nice use case).

I'm personally happy to improve VTE/g-t and the terminal emulation world in general using relatively small steps, but I never intended to redefine the very basics, which graphics would probably do. I'm totally happy with the cell-based approach. I personally do not miss sixel or any other similar support.

If it was solely me making decisions and having significantly more time to actually work on these, I'd rather ditch these ideas altogether, and instead move towards the model/view separation. That is, have a lower level VTE which is headless and only does the in-memory emulation, and a higher level widget on top of that. That way people could come up with alternative widgets that do cool-retro-term looks or implement ligatures or whatnot...

And going in this direction, I'd be happy to drop support for querying window position or pixel size like \e[13t, \e[14t, \e[19t (geez this latter one is so braindamaged!), or querying/setting iconized state, or anything else that doesn't make sense in headless mode. And of course, closing this bug too with wontfix.

But going in this direction would probably make it even harder to add any kind of graphics support.

Just a random dump of thoughts, no conclusion at all... Sigh...
Comment 5 Egmont Koblinger 2017-10-05 21:54:10 UTC
See also my other (similar) rant at bug 729204 comment 15.
Comment 6 Egmont Koblinger 2017-10-05 21:56:50 UTC
According to http://austingroupbugs.net/view.php?id=1151:

Apparently SIGWINCH is finally getting standardized (in POSIX?) along with two new functions tc[gs]etsize(), and midway in the discussion "ws_xpixel and ws_ypixel were removed from the proposal".
Comment 7 Egmont Koblinger 2020-05-27 15:31:50 UTC
Continued at https://gitlab.gnome.org/GNOME/vte/-/issues/251. Closing here.