Questions about windows support

Thu Feb 23 17:32:38 PST 2012

On 24 February 2012 12:03, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> On Thu, Feb 23, 2012 at 10:34:24PM +0100, Adam D. Ruppe wrote:
>> On Thursday, 23 February 2012 at 21:17:35 UTC, H. S. Teoh wrote:
>> >Taking the idea of an in-terminal video player further, what about
>> >a general escape sequence for "application-specific output"?
>>
>> <html>.....
>
> That gives you the funny situation where trying to edit a HTML file will
> interpret the tags instead of displaying them. If your editor is unaware
> of that, then you have the even funnier situation where editing a tag
> (i.e. temporarily breaking HTML syntax) will cause it to come out as
> text, and once you have a fully formed tag, then it magically gets
> rendered again. A twisted form of WYSIWYG. :P
>
>
>> seriously, once you take the in-terminal stuff too far, you
>> have a beast of a program that does everything; you end up
>> with something like a web browser or nested X server, and
>> you've lose the original beauty of the terminal.
>
> No, the idea is *not* to have the terminal do everything, but allow
> other programs to do it.
>
>
>> This is the path I started on, and ended up with what I called
>> the D Windowing System - which is still on my todo list, but
>> has been for a long time and will surely be for a long time
>> more.
>
> lol... I suppose.
>
>
>> But, I started with a terminal that can optionally output
>> images. Then wanted improved character display and figured
>> if it does images, it can be a bitmap drawable.
>>
>> Then wanted multiple channels... and at this point, you have
>> a poor man's X.
>
> True.
>
>
>> Realizing this, I went full into it and shifted gears to a higher
>> level X kind of thing, where you make an app based on widgets on
>> a grid, which would work in text mode or graphical mode. But, I
>> didn't get too far before work took over my time.
>
> Actually, I've thought of that before. It's something I'd love to have.
>
> The main complaint with writing a real X11 app is that *everything* is
> graphical, so to do something as simple as print a string requires an
> inordinate amount of code. You need to create a subwindow or
> subdrawable, load a font (with all that living nightmare that font
> resolution is), calculate font proportions, spacing, line wrapping, and
> do all of the above in an event-based model. At the end of the day
> you've reinvented a GUI toolkit with a text widget.
>
>
> [...]
>> But, on a terminal, I just don't think images are a fit there.  Might
>> as well just make something like a gui image viewer app and keep a
>> more traditional terminal.
>>
>> Though, I'd prefer to be more like vga text mode than VT100 in terms
>> of capabilities.
>
> The way I see it, it's a sort of "VGA-enabled text mode" terminal, where
> you can intermix graphics on what is basically a character grid. Not a
> full-fledged windowing system embedded in xterm.
>
> (I mean, with graphics capabilities the application *could* implement a
> windowing system, but that's the app's problem, not the terminal's.)
>
>
> T
>
> --
> One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

I have tried to keep the scope of what the graphics capabilities of
the terminal are down to a minimum, so all the drawing would still be
in terms of the terminal. I was thinking that you put it into graphics
mode, say how many columns and rows you want, and the length of the
data  (so as to not accidentally leave image mode because the data
contains the escape sequence for leaving image mode) It would start
drawing in a rectangle from cursor location, and leave the cursor in
the column after the last. I haven't decided what would happen if you
didn't have enough columns (rows would just scroll), or how you'd deal
with images that don't fit into character block pixel sizes.

So you could implement a fully graphical system inside it, but it
would be a lot of work, and you wouldn't have the advantage of any
windowing features, and everything would still be cursor-based anyway.
Basically the idea is to make it easy to implement features that make
sense in a terminal, but make it difficult to do anything outside that
scope. So I probably wouldn't have a subwindow, since that instantly
provides way too much functionality, also you could output pictures
fine simply by decoding the pictures into some "raw" format
(preferably something that can be mapped straight to a pixbuf) and
outputting them, video could work by just doing the same thing, but
moving the cursor back to the original starting point over-and-over.
Trying to make a graphical app would be a more of a challenge if you
want anything remotely complicated, and you'd end up just using X
anyway.

I guess the idea is that being able to, for example, display pictures
in your otherwise-terminal-based mail app is useful, being able to
preview files without opening a new window (useful for people with
tiling managers, like me) is useful. But having something that tries
to be a window manager, or a proper app, is not useful. By having a
layer of indirection, and the performance penalty that holds, trying
to maintain terminal context, and making it unidirectional, it
essentially forces apps to not abuse the capability, its not feasible
to do anything other than just display an image.

There are a few other idea I have, but aren't even close to being
properly formed yet, however the simple-to-use graphics capabilities
described above is something that I think has real merit. I've seen a
few similar things in the past, but I don't think they tried to be a
terminal emulator in their own right, so I couldn't run vim or screen
in them.