On Fri, Feb 24, 2012 at 02:32:38PM +1300, James Miller wrote: [...] > 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.
You could just pad the unused space with blank pixels. > 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. Right, 'cos the point isn't to implement a windowing system, but just to add graphical display capabilities to the terminal. > 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. Yeah that's pretty good basic functionality IMHO. Quite often I've wanted to write up some throwaway character-based games with graphical icons, and something like this would be perfectly suited. Usually these little games are just quick-n-dirty write-once-and-forget deals, so I really don't want to be dealing with the complexities of using X11 or SDL, but just to be able to say, character code X maps to image Y, draw this at character position (43,21). Job done. [...] > 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. Agreed. > 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. I think this has merit. It lets you do quick-n-dirty apps with simple graphical icons without needing to invest the effort into a full-fledged GUI app complete with a full windowing toolkit and configurable fonts. Sometimes just an icon or two in the midst of some text really is just good enough. T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
