Adding a single bit of protection in cell attributes to indicate they are either protected or become transparent (and the rest of the attributes/character field indicates the id of another terminal grid or rendering plugin crfeating its own layer and having its own scrolling state and dimensions) can allow convenient things, including the possibility of managing a grid-based system of stackable windows. You can design one of the layer to allow input (managed directly in the terminal, with local echo without transmission delays and without risks of overwriting surrounding contents. Asynchronous behavior can be defined as well between the remote application/OS and the local processing in the terminal. The protocol can also support an extension to provide alternate streams (take an example on MIME multipart). This can even be used to transport the inputs and outputs for each layer, and additional streams to support (java)scripts, or the content of an image, or a link to a video stream. And just like with classing graphics interface, you can have more than just solid RGB colors and add an alpha layer. The single-rectangular-flat grid design is not the only option. Layered approaches can then even be rendered on hardware easily by mapping these virtual layers and flattening them internally in the terminal emulator to the single flat grid supported by the hardware. The result is more or less equivalent to graphic RGB frames, except that the unit is not a single pixel but a whole cell with not just one color but a pair of colors and an encoded character and a font selected for that cell, or if a single font is supported, using a dynamic font and storing glyph ids in that font (prescaled for the cell size). The hardware then makes the rest to build the pixels of the frame, but it can be easily accelerated. The layered approache could also be used to link together the cells that use the same script and font settings, in order to use proportional fonts when monospaced fonts are not usable, and justify their text in the field (which may turn to be scrollable itself when needed for input). Having multiple communication streams between the terminal emulator and the remote application allows the application to query the properties and behave in a smarter way than with just static "termcaps" not taking into account the actual state of the remote terminal. All this requires some extension to TV-like protocols (using specific escape sequences, just like with the Xterm extensions for X11).
You can also reconsider how "old" mainframes terminals worked: the user in fact never submitted characters one by one to the remote application: the application was sending a full screen and an input form, the user on its terminal could fill in the form and press a "submit/send" button when he had finished inputing the data. But while the user was inputing data, there was absolutely no need to communicate each typed keystroke to the application, all was taken in charge by the terminal itself which was instructed (and could even perform form data validation with input formats and some conditions, possibly as well a script). In other words, they worked mostly like an HTML input form with a submit button. Such mode is very useful for small devices because they don't have to react interactively with the user, the transmission delays (which may be slow) are no longer a problem, user can enter and correct data easily, and the editing facilities don'ty need to be handled by the remote application (which today could be a very tiny device with in fact much less processing power than the terminal emulator, and would have in fact no knowledge at all of the fonts needed) A terminal emulator can make a lot of things itself and locally. And this would also be useful on many modern application servers that need to serve lot of remote clients, possibly over very slow internet links and long roundtrip times. The idea behing this is to allow to distribute the workload and decide which side will handle part of all of the I/O. Of course it will transport text (preferably in an Unicode UTF), but text is not the only content to transport. There are also audio/video/images, security items (certificates, signatures, personal data that should remain private and be encrypted, or only sent to the application in a on-way-hashed form), plus some states/flags that could provide visual/audio hints to the user when working in the rendered input/output form with his local terminal emulator. I spoke about HTML because terminal-based browsers already exist since long, some of them which are still maintained in 2019 (w3m still used as a W3C-sponsored demo, Lynx is best known on Linux, or elinks): https://www.slant.co/topics/4702/~web-browsers-that-run-in-a-terminal This gives a good idea of what is needed, what a good terminal protocol can do, and what the many legacy VT-like protocol variants have never treid to unify. These browsers don't reinvent the wheel: HTML is already fine to support this. And w3m is not restricted to show only text cells, it showcases the multilayered approach (even if these extra layers are not visible in Gnome terminal and similar, because their VT-like protocol does not have the necessary cababilities (this is where the VT-extensions are needed). And this is not just for "geeks" or technicians (or programmers that don't care at all about languages given they all speak a "tenchglish" jargon): such text-based web browser is also what is needed for accessibility (think about people with visual or aural deficiencies: HTML5 was too much focused on precise rendering on a graphic device for people with "normal" visual and aural conditions, and we've seen many websites abusing the offered facilities so much that their applications or graphic design became unusable by many, and not supprotable at all even with assistive technologies). Le ven. 8 févr. 2019 à 00:39, Egmont Koblinger <egm...@gmail.com> a écrit : > Hi Philippe, > > > I have never said anything about your work because I don't know where > you spoke about it or where you made some proposals. I must have missed one > of your messages (did it reach this list?). > > This entire conversation started by me announcing here my work, aiming > to bring usable BiDi to terminal emulators. > > > Terminals are not displaying plain text, they create their own upper > layer protocol which requires and enforces the 2D layout [...] Bidi does > not specify the 2D layout completely, it is purely 1D and speaks about left > and right direction > > That's one of the reasons why it's not as simple as "let's just run > the UBA inside the terminal", one of the reasons why gluing the two > worlds together requires a substantial amount of design work. > > > For now terminal protocols, and emulators trying to implement them; that > must mix the desynchronized input and output (especially when they have to > do "local echo" of the input [...] > > I assume by "local echo" you're talking about the Send/Receive Mode > (SRM) of terminals, and not the "stty echo" line discipline setting of > the kernel, because as far as the terminal emulator is concerned, the > kernel is already remote, and it's utterly irrelevant for us whether > it's the kernel or the application sending back the character. > > SRM is only supported by a few terminal emulators, and we're about to > drop it from VTE, too (https://gitlab.gnome.org/GNOME/vte/issues/69). > > > If you look at historic "terminal" protocols, > > I'm mostly interested in the present and future. In the past, only for > curiosity, and to the extent necessary to understand the present and > to plan for the future. > > > Some older terminal protocols for mainframes notably were better than > today's VT-like protocols: you did not transmit just what would be > displayed, but you also described the screen area where user input is > allowed and the position of fields and navigation between them: > > This is not seen in today's graphical terminal emulators. > > > Today these links are better used with real protocols made for 2D and > allowing an web application to mange the input with presentation layer > (HTML) and with javascript helpers (that avoid the roundtrip time). > > Sure, if you need another tool, let's say a dynamic webpage in your > browser, rather than a terminal emulator to perform your taks > effectively, so be it. I'm not claiming terminal emulators are great > for everything, I'm not claiming terminal emulators should be used for > everything. > > > But basic text terminals have never evolved and have lagged behind > today's need. > > I disagree with the former part. There are quite a few terminal > emulators out there, and many have added plenty of new great features > recently. > > Whether they're up to today's needs, depends on what your needs are. > If you need something utterly different, go ahead and use whatever > that is, such as maybe a web browser. If you're good with terminals, > that's fine too. And there's a slim area where terminal emulators are > mostly good for you, you'd just need a tiny little bit more from them. > And maybe for some people this tiny little bit more happens to be > BiDi. > > > Most of them were never tested for internationalization needs: > > Terminal emulators weren't created with internationalization in mind. > I18n goals are added one by one. Nowadays combining accents and CJK > are supported by most emulators. Time to stretch it further with BiDi, > shaping, spacing combining marks for Devanagari, etc. > > > [...] delimit input fields in input forms for mainframes, something that > was completely forgotten and remains forgotten today with today's VT-* > protocols, to indicate which side of the communcation link controls the > content of specific areas > > Something that was completely forgotten, probably for good reasons, > and I don't see why it should be brought back. > > > As well today's VT-* protocols have no possibility to be scriptable: > implemeint a way to transport fragments of javascripts would be fine. > > I have absolutely no incentive to work in this direction. > > > Text-only terminals are now aging but no longer needed for user-friendly > interaction, they are used for technical needs where the only need is to be > able to render static documents without interactiving with it, except > scrolling it down, and only if they provide help in the user's language. > > Text-only terminals are no longer needed??? Well, strictly speaking, > computers aren't needed either, people lived absolutely fine lives > before they were invented :) > > If you get to do some work, depending on the kind of work, terminal > emulators may or may not be a necessary or a useful tool for you. For > certain tasks you don't really have anything else, or at least > terminals are way more effective than other approaches. For other > tasks (e.g. text editing) it's mostly a matter of taste whether you > use a terminal or a graphical app. For yet other tasks, terminal > emulators take you nowhere. > > My work aims to bring BiDi into terminal emulators in a reasonably > well designed way, rather than the ad-hoc and pretty broken ways some > emulators have already attempted this. If this is what you were > looking for (as many people are), good for you. If you don't care > about it, because let's say you'd rather use other tools to get your > BiDi work done, so be it, that's also fine. > > > Why not imagine a text -terminal with attributes deliminting a > rectangular area containing an object in which rich-text (HTML or other) > will be rendered and controled by the 2D/3D engine and left unmanaged > internally by the terminal protocols? > > Because I'm not redesigning the essentials of terminal emulators, just > bringing BiDi into whatever these terminal emulators already are. > > Because probably all the terminal emulators are developed by a few > enthusiasts as a hobby in their pretty limited free time, so they go > for what is reasonable to implement, is likely to be used by > applications, and what they think makes sense. > > > Old terminal protocols based on a single regular grid of equal cells are > definitely not user friendly and not suitable for all international text > (only a few scripts allow readable monospaced fonts). > > Terminals are, in many aspects, not user friendly. The best you can > tell about them is that they're poweruser friendly and developer > friendly. > > How much they are suitable for international text depends on how much > compromise someone is willing to make, e.g. whether they're ready to > accept monospace fonts for their language's script. If nothing else, > my proposal at least makes terminals usable for Hebrew. However, in > plenty of terminal emulator's bugtracker there's a request for BiDi, > they usually demonstrate it with Arabic, and show examples of other > terminal emulators that do some BiDi as reference. This means that for > most people requesting BiDi, having monospace fonts for Arabic (plus > shaping I assume) is apparently a good enough compromise. > > > Today we need more flexibility. > > Sure. You get it outside of terminal emulators. Or you can start > changing terminal emulators to accomodate to the new needs, put all > the work in that (or hire someone to do it), and see where it goes. > > I, for one, am not to the slightest bit interested in abandoning the > character grid and allowing for proportional fonts. This would just > break a gazillion of things. Nor am I interested in reviving local > echo, introducing rectangle areas where data can be typed into; nor > making emulators scriptable by an app sending e.g. JavaScript code to > them. > > What I am interested in, for whatever reason, is bringing BiDi into > the existing world of terminal emulators. > > > But it will be difficult to readapt these old protocols to support the > necessary extensions and remain compatible with applications still using > them. > > You see it as difficult, I see it as a challenge that requires buy-in > from so many parties and modification to so many software that I don't > see it viable. > > To summarize: Terminal emulators currently have a strict character > grid model, and tons of other pecularities, limitations and legacy to > live with (and features that have practically died over the decades). > What I do is bring BiDi into this world (in its current state) with as > little modifications to the basics of terminal emulation as absolutely > necessary. If you have ideas for other small, incremental changes, I'm > curious to hear them! If you'd like to see way more substantial > changes to the very core of terminal emulation, like proportional > fonts, JS code downloaded to the terminal etc., I'm not the right guy > to talk to; thanks for your understanding! > > > cheers, > egmont >
