On 24 February 2012 12:03, H. S. Teoh <[email protected]> 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.
