Questions about windows support

[H. S. Teoh]

On Fri, Feb 24, 2012 at 12:38:52AM +1300, James Miller wrote:
> On 23 February 2012 19:41, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
[...]
> > Perhaps there's a way of detecting JPEG or PNG output, say some kind
> > of magic number detection ala /usr/bin/file. Buffer the first few
> > bytes at output at the start of new lines, and if it looks like a
> > JPEG file, buffer the rest of the output instead of displaying it
> > immediately, and if after reading more input it does appear to be a
> > valid JPEG file, then display it as an image.  Otherwise flush the
> > buffer and display it as text.
[...]
> > Or you can do it the easy way by having a dedicated escape sequence
> > that switches to image mode, and write a wrapper for cat that
> > outputs this sequence when it detects image data in its output.
[...]
> I was thinking about both of those options and came to pretty much the
> same conclusions. What would be cool would be to add in new STD* file
> descriptors (ala STDIN, STDOUT, etc) that are dedicated to
> presentation (also means that you can output things to the terminal
> while running a pipe), however that would also require shell support
> (to set the correct FDs on the child process) and I'm not writing a
> terminal /and/ shell (yet).

Well, currently you *can* output to terminal in a pipe by writing to
stderr, which usually points to the terminal even if stdout has been
redirected. Of course, the user can redirect stderr too, but in that
case he doesn't *want* any terminal output, so there's no point fighting
it.


> Otherwise, I think having the terminal take note of what is going on
> in the shell would solve the stuck mode problem, (which i encountered
> accidentally by putting my terminal into alt_charset mode) just have
> it notice if the current process is a shell or not and basically say
> "Shells can't be in image mode". It would probably require grabbing
> /etc/shells.

The problem is that the terminal doesn't know who's sending output to
it. It's just reading one end of a pipe, and anything could be at the
other end, and there could be an arbitrary number of stuff in between.

I'm not sure I know any easy and reliable way to solve this.


> The other advantage of using an escape sequence is that assuming that
> it can read fast enough, then it could easily be extended to all sorts
> of things, video for example. Displays a small video in the terminal,
> so you can check that the video is what you actually want, don't
> replace an actual movie player, that would be silly. you could also
> have things like syntax highlighting for supported files.

Actually, if the terminal supported video output, you could actually
have the movie player play inside the terminal. :P Or am I just being
silly?


> As you can probably tell, I am less than enamored by the current
> terminal/shell line-up we have, I just think that there is so much
> more we could do with modern tech, and it doesn't need to even be
> incompatible with older systems!

True.

Taking the idea of an in-terminal video player further, what about a
general escape sequence for "application-specific output"? This can then
be used along with file type (data type) detection to multiplex between
different apps, like image display, movie player, sound player, etc..
The apps will have access to a given region on the terminal screen
(perhaps passed as a subwindow on the underlying windowing system), and
can do whatever they want with it.

This also means you don't need ncurses anymore. The app can get direct
access to the terminal as a graphical drawable, and can do much more
than displaying a bunch of characters in a grid.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford