Questions about windows support

[H. S. Teoh]

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)