Enlightenment Terminal Allows Video Playback, PDF Viewing

An anonymous reader writes "The E17 Enlightenment project has released a new version of its Terminology terminal emulator. With Terminology 0.3 comes several fancy features, including the ability to preview video files, images, and PDF files from within the terminal. There's new escape sequences, inline video playback, and other features to this terminal emulator that's only built on EFL and libc."

Comments

rio

[Anonymous Coward]

sigh like a cheap plastic imitation of plan9's drawterm

Yep there goes the neighborhood.

[BluPhenix316]

Now geeks will never leave the terminal

Can it do...

[c0lo]

Can it do all the above inside lynx? 'Cause if not, I'm going to wait a bit for the emacs module.

(grin)

(tell me again: why would someone want to do any of the above in a terminal?)

Re:Can it do...

[Anonymous Coward]

You and me? Nope.
Hollywood and public mindshare? Yup

Re:Can it do...

[Ash Vince]

(tell me again: why would someone want to do any of the above in a terminal?)

After having watched the full video of its capabilities I am pretty amazed and certainly some of it will be useful.

I particularly liked things like the ability to use ls to a get a list of files but with small thumbnails next each. You were then able to select the thumbail and see a bigger preview for images and movies. I also like the ability to do things like hover over a file in a "ls" output then just click and drag it but getting a full path to the file.

Re:Can it do...

[LateArthurDent]

(tell me again: why would someone want to do any of the above in a terminal?)

Because if you're working at a terminal, leaving the command-line is always a pain in the ass?

Re:Can it do...

[raster]

'Because I can' ... yup.

  Seriously though it's zero extra code to handle video in a bg when it's already supported in Popups. It's the same object. It's supported in popups because it's helps people who use terminals for irc, email and more and when they have a link to a video stream they get easy one click access. Users of irssi have been singing terminology's praises for this. There are tonnes of legitimate normal uses of such features. You might not see it now or your usage of terminals is incredibly narrow, but many who live in them all day find these features a godsend.

Re:Can it do...

[Anonymous Coward]

> Because if you're working at a terminal, leaving the command-line is always a pain in the ass?

OSX has a cool feature that makes it a bit less of a pain. It has a command-line "open" tool that has the same effect as double-clicking a file in the file browser. In particular, I often use "open ." to open the current folder in the file browser.

A GUI-aware terminal is of course way cooler.

Re:Can it do...

[raster]

Terminology also does this if it doesn't know the media file type or it's a directory and it asks a generic open tool to deal with it. ( Configurable). Thus it opens with your favorite tool or even a file manager view.

Re:Can it do...

[Deltaspectre]

I often use gnome-open for that same purpose.

Re:Can it do...

[c0lo]

(tell me again: why would someone want to do any of the above in a terminal?)

Because if you're working at a terminal, leaving the command-line is always a pain in the ass?

Ass... mmchhh... that's not what I fancy.
But I'll grant you the point: for some terminal (ends of the body) to be worked at, this could be tremendously effective. Exempli gratia (adjust to your taste):

cd ~/MyCollection
find -type f -name "*.ogg" -exec grep --video-frame-content "wild-riding|yeehaaa" {} \; | play

Re:Can it do...

[Vaphell]

gnome-open or xdg-open ftw

Re:Can it do...

[Anonymous Coward]

Now that he has seen that it can be done without creating a community-wide fuss or massive regression like KDE or GNOME do each time, he has nothing good to say, so he regresses to poking at the whole purpose when he would probably be the guy complaining about how this package sucks this way, that one sucks that way and so on.

Some people just can't appreciate a piece of software done well.

Cranks're gonna cry, bitches're gonna bitch.

Ignore them (even if they have 3-digit Slashdot ID's because smaller ID's dont mean squat) if they can't appreciate good software.

Re:Can it do...

[Anonymous Coward]

Who the hell uses Lynx anyway? Links or ELinks is better.

Re:Can it do...

[Hatta]

it's helps people who use terminals for irc, email and more and when they have a link to a video stream they get easy one click access. Users of irssi have been singing terminology's praises for this

You don't need viewers integrated into the terminal for that. Just an URL aware terminal(e.g. urxvt) and something like xdg-open.

Solutions already exist that follow the UNIX philosophy. Do one thing, and do it well. Don't stick a PDF viewer into the terminal. Make a kickass terminal, and a kickass PDF viewer, and glue them together.

Re:Can it do...

[Anonymous Coward]

Can you honestly say you've never wanted to split your terminal into four separate panels, having garish (and even moving!) picture backgrounds which make your commands and output completely unreadable? Or that you've never _ever_ wanted to watch a movie which partially obscures another movie playing in the background, with text on top?

You, sir, need to raise your expectations!

Re:Can it do...

[UnknownSoldier]

All the power-users have ways to "Open Command Prompt here" from the GUI and the dual: open the GUI File/Folder Explorer from the shell:

To go from Command Line --> GUI with Bash

if [ "$TERM_PROGRAM" == "Apple_Terminal" ] # OS X
then
  alias x='open .'
elif [ "$COLORTERM" == "gnome-terminal" ] # Linux - Ubuntu Gnome
then
  alias x='nautilus .'
else # Windows (need .bat file in CMD.EXE)
  alias x='explorer /e,.'
fi

Re:Can it do...

[raster]

what you don't get is.. the pdf comes for free if you do images/svg's etc... that's the point of libraries. and there is a vast difference between writing a full pdf viewer and something that just happens to display them because its whole toolkit stack gives it that for free.

as for your quoting of unix philosophy... it's like the church saying the world is flat and people being too scared to get in a boat and sail west from europe lest they fall off the edge of the world! why does everything have to religiously obey some specific philosophy? why do we have to limit ourselves to a tiny little box when creating things because you wish to quote some philosophy? terminology already supports links. already supports xdg-open stuff (run a command on a click). it HAPPENS to sit on top of a toolkit bas that just to add a nice feature of "give me a background" HAPPENS to at the same time let you do pdf's in a bg or videos or pop them up for a tiny little bit of ui work (place object above text in a container). the library set is modular. the pdf and svg loading is in fact handled by external processes and piped through library layers to hand you an image object - and at that point you don't much care where it came from. the blind adherence to "unix philosophy" means you never INTEGRATE. you never get to this point of "wow... everything .. JUST WORKS", because you stop thinking out of the box.

Re:Can it do...

[raster]

it's a demo for crying out loud. it's meant to show off as much as possible in a short space of time, NOT show you how you MUST use it every day. a looping video of a dark night sky with clouds drifting by etc. would be perfect. doesn't obscure your text BUT provides a nice "pattern". i don't happen to have such video content with me right now. imagine:

http://www.flickr.com/photos/christopics/118890688/

but without the people, (and the pool right at the bottom, not the middle), with the video edited to loop seamlessly.

the point of features is to make it POSSIBLE, with visual content. given the logic of "don't have features because gasp. someone may not provide perfect content" would imply we should not ever set wallpapers on our desktops because.. GASP.. it may clash with icons/text content there and may make it hard to read! just create/find appropriate content.

Re:Can it do...

[JabberWokky]

I use dolphin's synced terminal and file view quite a bit. Some tasks are easier with a mouse (picking out a subset of files by previewing them) and some tasks are easier with a terminal (running imagemagick across a slew of files). Having a terminal integrated into a GUI file manager makes sense. This is simply moving toward the same kind of thing from the other direction, adding these things things in a terminal-focused interface.

Just like the other cool kids

[Anonymous Coward]

For every window manager, there's a terminal wishing it were a window manager.

Re:Just like the other cool kids

[c0lo]

For every window manager, there's a terminal wishing it were a window manager.

Why have a window manager at all when one may have emacs?

Re:Just like the other cool kids

[Celarent Darii]

And every window manager wishing it was a terminal. That damn mouse is one of the most inefficient things for input.

This new terminal thing looks great. I wonder if emacs -nw would display images in it.

Re:Just like the other cool kids

[lahvak]

Why have a window manager at all when one may have emacs?

Because viper is not quite good enough yet.

Re:Just like the other cool kids

[Anonymous Coward]

What's it missing that you want?

Re:Learn the truth... apk

[Soylent Beige]

That's what she said!

Looks Similar

[Anonymous Coward]

This reminds me of something akin to Mathematica notebook with more focus on being a functional terminal.

Re:Looks Similar

[lahvak]

Imagine ipython or isympy optimized for this terminal.

So

[mybeat]

How long will it take for the "Terminology is a great OS, all that is lacking is a terminal" joke to be relevant?

Re:So

[chromas]

Judging by the time it took to get E17 out, I'm not so sure that any of us will still be alive by then.

Re:So

[jonadab]

I'll go along with that. E17 has only been in development since somewhere around the same time Microsoft first started working on what would eventually become Windows XP. I'm not entirely certain whether this is an exaggeration or not. My memory is pretty good, but we're talking about a LONG time ago. Like, several major versions of Emacs ago, maybe half a dozen Debian releases ago, and before the last official version of NetHack came out, if I'm not mistaken. I'm not certain, but I think maybe E17 was already being promoted before Mozilla 1.0 came out. No, I do NOT mean Firefox 1.0. In fact, it might've been clear back when Mozilla versions started with M for Milestone. Like I said, the exact timeframe is a little hard to pin down clearly in my mind. All I know for sure is, it was Back In The Day.

mingw?

[Anonymous Coward]

does it run under windows?

In ASCII?

[Anonymous Coward]

It's not just a terminal emulator anymore is it?

Security implications do not look good

[tamyrlin]

The demo video they have look really cool and I like any idea that improves the usability of the terminal. I just hope that they have some strategies in place to minimize the security impact of adding a large amount of potentially vulnerable code to a critical service such as the terminal (e.g., using securecomp or other mechanisms to sandbox the potentially vulnerable code).

Re:Security implications do not look good

[Anonymous Coward]

The demo video they have look really cool and I like any idea that improves the usability of the terminal. I just hope that they have some strategies in place to minimize the security impact of adding a large amount of potentially vulnerable code to a critical service such as the terminal

Do not innovate. It might not be secure.

Re:Security implications do not look good

[drinkypoo]

It's no more dangerous than having those programs around for the user. Let programs run a less-enhanced terminals when they need to run one automatically, let the user launch the fancy terminal from an icon.

Re:Security implications do not look good

[Anonymous Coward]

It is more dangerous, especially if it automatically displays these files and has any vulnerabilities in the terminal or associated display libraries. xterm for all its flaws doesn't try to open malformed pdfs by default.

Re:Security implications do not look good

[tamyrlin]

In theory, yes. In practice no, if you consider the fact that ls might very well be exploitable through malware infested files in this scenario. (I think all sysadmins shudder at the thought that merely listing the contents of a directory with malware in it could be dangerous...)

However, there are ways around this. IIRC chrome decodes images inside a seccomp jail, causing an exploit in the image decoder to be very hard to use for anything except showing a a naughty image and eating CPU time. (I don't know if the enlightenment guys are doing this or not, but I hope they are considering it at least.)

Re:Security implications do not look good

[drinkypoo]

Most users are already running a file manager which decodes files willy-nilly for the purpose of thumbnailing. This is directly comparable.

I would also have imagined that by now there are image decoding libraries which never, ever trust the contents of the file, which have limits-style protection for excessively large images, and the like. It has always boggled my mind that anyone would ever write a file decoder which trusted the file's contents. Even in a world without malware, there is still data corruption.

Re:Security implications do not look good

[lennier]

Do not innovate. It is guaranteed to not be secure.

Very much so. That's the depressing reality of the Internet in 2013.

Things might be different if we had languages and platforms which didn't actively conspire against us.

Re:Security implications do not look good

[lennier]

I would also have imagined that by now there are image decoding libraries which never, ever trust the contents of the file, which have limits-style protection for excessively large images, and the like.

That's what I imagined too, but it seems like all the professional working programmers who wrote industrial-strength image parsing libraries just didn't bother to do any security checking at all and took all sorts of unsafe shortcuts. And then were really surprised to find that their 100% bulletproof code had been exploited.

I suppose I shouldn't really be surprised, given the corruption and meltdowns going on in other 'industrial strength' fields like, say, mining, or global banking -- but I always used to think that programming was a world apart, that we lived in a more ethereal plane and were a bit smarter, less easily swayed by snake oil and more honest than the average corporate executive or politician.

Seems not! Internet security is our generation's disaster - we built it, we didn't bother to check our premises, we own it. Oops!

Re:Security implications do not look good

[Anonymous Coward]

"industrial strength" = "needs babysitting".

Think about it.

Re:Security implications do not look good

[raster]

it's no more dangerous than a filemanager that automatically displays thumbnails too.

Re:Security implications do not look good

[jonadab]

> Things might be different if we had languages and
> platforms which didn't actively conspire against us.

We sort of do (well, much better anyway), but everybody keeps using C (or C++, just as bad) for application development, because, you know, *serious* languages give you six loaded machine guns and no convenient way to carry them except in holsters that aim the muzzle directly at your feet. Languages that do not do this are "scripting languages" and are "fine for quick one-off stuff" but "no good for big projects". I don't know where this idea comes from, but it is pervasive. VHLLs get no respect.

Oh my dog!

[Anonymous Coward]

This is the prettiest thing since Jessica Alba!

Seems logical..

[AdmV0rl0n]

The terminal is an echo from the past, even with all the things added like shells and so on. It makes sense that someone make a terminal that can in fact operate just like a window manager can, with the added power that can bring. Seems to me that with things like HTML5 - that weaving this into a nice terminal (which care of the video seems to be what they have done).

Its still a little rough around the edges, and it looks a bit like it needs more work in terms of UI and polish, but someday all terminals might work this way.

Re:Seems logical..

[MrHanky]

Is this some kind of parody?

Re:Seems logical..

[JasterBobaMereel]

Terminal : Low bandwidth, low resources way of accessing the system often remotely by experienced technical users

This Terminal : High bandwidth, high resources way of accessing the system bad for remote access and friendly to inexperienced non-technical users ....

Who is this for ...?

Re:Seems logical..

[AdmV0rl0n]

No, Terminal was originally simply the crippled ways users (I'm using the term with some sarcasm) had to use just to get access to a computer..

And the age of the 56k modem is applicable in a minority of cases, move on.
And to quote jobs, when he was at Parc Xerox - and he saw the future, he said once seen all computers will work that way. It was just obvious.

And further, friendly to users is a good thing. I meet many who argue otherwise, and they are wrong. Nuff said.

Re:Seems logical..

[realityimpaired]

This terminal's not high bandwidth at all... I can't comment on the resources. I switched back to lxterminal because I don't like how it handles tabs or transparency.

That being said, it had no issues at all SSH'ing into my server over a cellular connection, and I have no reason to think that it's actually going to increase the amount of data being transferred.

Unless you're stupid enough to try to run it remotely from the server, and use something like nx or vnc to display it locally....

Re:Seems logical..

[flymolo]

I like it. I'm often annoyed at the split between the GUI and command line. What if I want to run a find and view the images or videos that result? Or I write a program that produces images, and I want to test many parameters without having to write a GUI to view the results. This allows shell script style programming to interact with graphical data, and that is something I've wanted for a while.

Re:Seems logical..

[Dixie_Flatline]

This is for people that like to work in the terminal--instead of a file browser--but still want to look at all their files.

When the UNIX terminal was invented, there weren't a lot of things to look at other than text files. Times have changed somewhat since then.

The terminal is often the best place to get work done, and sometimes you don't want to go into a file browser or fire up an external viewer just to look at a PDF. Being able to preview a file so you can correctly sort it into a directory, for instance, seems like a good use of this upgrade.

In OS X, you can get something like Pathfinder that lets you manage your files graphically, but has an attached shell if you need one. This is just a more terminal-centric view of things. You can still work text-only, if you like.

Re:Seems logical..

[raster]

Please become informed before claiming things you have no clue about. It does everything your current terminal does (more or less if we talk of vt100/200 and friends) the same way. It ALSO adds extended escapes and inside these all it sends is file paths or uri text. If you call a file path high bandwidth then ok, guilty. But I think you are simply living up to slashdots reputation in the users category of blowing hot air.

Re:Seems logical..

[serviscope_minor]

I meet many who argue otherwise, and they are wrong.

I don't think I've ever heard anyone advocating an unfriendly system.

What people advocate often is an expert friendly system that makes no particular effort for novice friendliness.

Most proponents of "user friendliness" tend to tell the experts that they don't want what they want and noone cares anyway.

Re:Seems logical..

[Anonymous Coward]

This is how linux on the desktop can look too.

It's FOSS, FFS, people do things to scratch an itch, take it if you like it else leave it.

Re:Seems logical..

[Hatta]

sometimes you don't want to go into a file browser or fire up an external viewer just to look at a PDF.

Why not? Why would you want to load a PDF viewer and movie player every time you want to pop open a shell? Doesn't loading the PDF viewer as needed make more sense?

As far as I'm concerned, make the output of 'ls' drag&dropable and call it done. That's all the GUI integration the terminal needs.

Re:Seems logical..

[Anonymous Coward]

There are many different terminals with low bandwidth requirements. These are not going anywhere. However, if you are accessing your local system and bandwidth is not an issue, and you would find these facilities useful (I know I might sometimes like file previews etc. when using the terminal) then this is a clever and positive enhancement, reducing the need to swap between terminal and gui.

You seem to be either of the school that says "This is no good for what I want so it's bad" or "Choice is bad".

Re:Seems logical..

[Anonymous Coward]

$ $FILEMANAGER `pwd`

done.

Re:Seems logical..

[Dixie_Flatline]

Well, if you get right down to it, this is what most graphical file browsers do already. So if I open up the Finder or Pathfinder in OS X, I get a previewer for all sorts of files automatically loaded. If I highlight a file and hit the spacebar, I get a preview of the content (or, really, you just see the content outside of a specific viewer; 'preview' is the the terminology that Apple uses, but it's not strictly correct). All this terminal application is doing is making it so that if you prefer to work in a terminal to manipulate and view files, you have the same functionality as a GUI filebrowser.

It's certainly the case that I use and appreciate the functionality of this quickview system in OS X, and I definitely would appreciate it when I have a shell open. I still do a lot of operations in the shell when I'm working in OS X because that command line interface is often still just much better.

I suppose that in the end, the question is why we would not build something like this in if we can. If it's implemented well, you wouldn't see a performance penalty when doing simple operations, but it's a massive expansion of utility and prevents switching to a different application when all you want to do is quickly scan the content of some items to understand what to do with them.

Re:Seems logical..

[sootman]

A couple small notes about the OS X terminal -- I'm not saying this Enlightenment thing is bad or not needed or Apple did it first, but just vaguely related, and of possible interest to people reading this thread...

- drag a file from the Finder into Terminal and it writes the path.

- `open` will open files, folders, or apps. `open .` will open the directory you're currently in. `open foo.txt` will open foo.txt in your default text editor, same as if you had double-clicked it in the Finder. I wrote a script called 'blank' that creates new blank documents: `touch $1` followed by `open $1` to create a new empty (text) file and open it in my default GUI editor.

- `pbcopy` copies standard output to the clipboard. `pbpaste` gives the clipboard as standard output. So you can do things like `ls | pbcopy` to copy a list of folder contents to the clipboard. (Though Mac/Unix/DOS line break differences can cause issues.)

Re:Seems logical..

[Hatta]

All this terminal application is doing is making it so that if you prefer to work in a terminal to manipulate and view files, you have the same functionality as a GUI filebrowser.

I already do. If I'm at the command line and I want to view a file, all I have to do is type "preview file.pdf". Apple's Preview is just another application.

Re:Seems logical..

[lahvak]

The reason I like this is that it seems to be good for everybody. inexperienced non-technical users will find it easier using a terminal, while experienced users will get to use a terminal just like before, with added stuff that does not seem to get in the way. I would like to know how configurable all the graphical stuff is. Can I add graphics into my shell prompt? I guess since it works using escape sequences, the answer is probably yes. Including a little sparkline displaying system load, or a miniature image of the filesystem tree into your prompt, that sounds pretty useful to me.

I bet that we can probably find old usenet posts from people complaining about color terminals, saying that that sort of eye candy is good only for inexperienced users, the real men use only green phosphor.

Re:Seems logical..

[lahvak]

make the output of 'ls' drag&dropable and call it done.

I *hate* grag&drop. What I would like would be a feature like vimperator or pentadactyl, or maybe lynx numbered links, where a hotkey would make all displayed files, paths and objects in general labeled in some way, and I could start applications on the labeled objects, or use the labels on the command line in some way.

Re:Seems logical..

[raster]

bingo. it's a terminal at its core and does all the things a regular terminal does. it ADDS things you CAN use. you CAN set a background to an image fine - most terms can since i added that to rxvt many years ago and started the trend (rxvt-xpm became eterm and then everyone copied). there is nothing wrong with ADDING some bonus features. the libraries already do all the work. the code and features are there. it's generic code. there is no good reason to specifically disallow such things just because it's a terminal. if its possible to add and you spend a little effort on it, then why not?

Re:Seems logical..

[Anonymous Coward]

I used to have a 5 line terminal in a separate pane in my Konqueror session linked to the browser working directory.

Re:Seems logical..

[raster]

you can put imagery into your prompt indeed.. as long as the imagery is only of green phosphors! :)

Re:Seems logical..

[jthill]

#1 I miss too. #2 is `open() { xdg-open "$@"; }`. #3 is `xclip`.

Also I miss rewrapping output (that maybe more than the dnd, having to reissue a command because of truncated output is just a waste of my time) and the kerning.

WOW!

[Saija]

I am the only one impressed by the demo? I mean, it's a terminal displaying pictures, videos and letting you set that as background, don't know how util that could be but, wow! my inner child have a birthday party just seeing that demo video

Re:WOW!

[Anonymous Coward]

I was impressed at first, but I realized, this is not a terminal displaying pictures. This is a window manager that looks and acts like a terminal.

Can it access media over ssh?

[hankwang]

I wonder whether it works if you ssh into another machine. I have been wanting something like that while logged into my media server, which doesn't have X11 applications installed. It's not mentioned in the feature list and I can't judge whether the underlying architecture would allow tunneling these functions over ssh to a box that doesn't have enlightenment installed. I'd think that a special ssh client on the client side would suffice to have simultaneous channels for command-line data and multimedia data to the host machine.

Re:Can it access media over ssh?

[Kagetsuki]

Not related to in-terminal preview but to stream over SSH have you tried mounting the remote location and streaming with sshfs? I've done it before and as long as the link is stable it seems to work fine (even for video).

Re:Can it access media over ssh?

[raster]

Sorry. Doesn't work over a remote shell. Has to be local atm. Haven't figured out how to sensibly do it remotely.

Re:Can it access media over ssh?

[hankwang]

have you tried mounting the remote location and streaming with sshfs?

Yes, I tried. But things like mass re-tagging media (ogg vorbis) files are very slow if the actual file content needs to be sent back and forth over wi-fi, compared to doing the file operations locally on the media server.

Re:Can it access media over ssh?

[hankwang]

Doesn't work over a remote shell. Has to be local atm. Haven't figured out how to sensibly do it remotely.

Do you say this as a beta tester or as a developer?

I suppose that one could implement the 'tyls' replacement for ls without all the GUI libraries (probably a 20 line perl script could do the job). Maybe without thumbnails, but at least with hyperlinked filenames. If the filenames are then encoded as, e.g., sftp://host/path/foo.jpg, then it would not be too hard to implement a handler inside terminology.

Re: Can it access media over ssh?

[raster]

I say this as the guy who wrote it... came up with the escaping side Chanel data scheme and wrote most of the library code it depends on in efl. :)

Re: Can it access media over ssh?

[hankwang]

I just had a look at tyls.c; it looks to me like the escape codes have the filename and a generic icon identifier ("like "application-x-tar") embedded, or no icon identifier if it is a media file. I assume that the terminal client then looks up the file and generates the thumbnail.

Why is it infeasible to use URIs rather than pathnames, so that the terminal can fetch the data? I understand that it's more work than adding three lines of code, but your wording "Haven't figured out how to sensibly do it remotely." sounds like there is a more fundamental problem.

Re: Can it access media over ssh?

[raster]

it already does uri's... just provide http://blahlahblah.com/blah instead of /path/to/file and it'll fetch it. here's the catch - that;s not useful as WHO will serve it? what URL? what webserver? won't work over ssh. wont work OVER your connection. it has to work VIA it to be feasible.

now to display a thumbnail i could have tyls generate small low res thumbs itself and embed the thumbnail image inside escapes and send it down the terminal pipe, but this will only work for small thumbnails - what if i want to ... play video? then we have to stream the entire video via an escapecode... and that;s just awful! i am not ready for THAT level of evil.

btw. thanks so much for being an informed user who will bother to look at the code before rabbiting on about vague unfounded assumptions. :) i guess it's sad that i have to even say this. :) anyway - and tyls.c is ugly as. it was a quick test program i brewed to test the escapes it is not at a nice piece of code... :) it needs some love.

Re: Can it access media over ssh?

[hankwang]

what URL? what webserver? won't work over ssh. wont work OVER your connection. it has to work VIA it to be feasible.

I'm using Gnome 2 and Compiz, so I'm not sure whether this translates to your platform, but in the Gnome file manager I can enter sftp://username@hostname:/home/username/foo.jpg . I guess the problem is figuring out as which hostname the server is accessible, which will probably mean an old-style ~/.tyls configuration file ("When logged in from 192.168.1.14, then prefix the pathnames with sftp://bob@192.168.1.5/"). Since this is completely separate from Terminology itself, one could implement this right now as a lightweight Perl script that can run on a NAS.

now to display a thumbnail i could have tyls generate small low res thumbs itself and embed the thumbnail image inside escape

Well, for remote hosts I think a generic "This is an image" or "this is a video clip" icon should do, otherwise you might be sending huge amounts of data over a 1 Mbps data connection.

Re:Can it access media over ssh?

[lahvak]

He is saying it as the rasterman, duh!

Re: Can it access media over ssh?

[raster]

correct. what is the hostname that is visible FROM one system TO the other? who knows. you may ssh through several natted gateways into an internal network. i do this all the time actually. it simply wont work then (the sftp:// idea). i am not fond of the configuration idea. oh and it handles uri's but not sftp - http/https/ftp sure, but that doesn't solve the issue here. to work right it needs to transport via the terminal stream, and that's where i haven't decided on a sensible solution. i've given it some thought, but if i'm going to bother, i'm going to "make it right" so it works not just over ssh, but over telnet or anything else and goes through hops (ssh to a, then from a ssh to b, then ssh to c - and b and c are inside a nat behind a).

VERY poor choice of escape sequences

[ciggieposeur]

They should have used the future-proofed OSC, DCS, SOS, PM, or APC prefixes instead of this new ESC{ sequence. And then they terminate the sequence with a control character (NUL)! This is worse than "ANSI music".

Terminology authors, if you are reading this, could you PLEASE talk to Ted Dickey (xterm and ncurses maintainer) about the RIGHT way to do this? Otherwise you're going to find yourselves with your own version of brokenLinuxOSC.

Re:VERY poor choice of escape sequences

[Anonymous Coward]

"future-proofed"? Everything that has been designed to be "future-proofed" has proven not to be. Less marketing speak plix!

Re:VERY poor choice of escape sequences

[Anonymous Coward]

PLEASE talk to Ted Dickey (xterm and ncurses maintainer)

Tom Dickey?

Re:VERY poor choice of escape sequences

[Anonymous Coward]

His name's Thomas Dickey, not Ted Dickey. :-)

Re:VERY poor choice of escape sequences

[raster]

And what is wrong with this? It's the same style as xterm title set escapes. ?

Re:VERY poor choice of escape sequences

[ciggieposeur]

The two problems I'm seeing (Dickey may see more) are:

1) The sequences use a non-standard opening. This means for terminal writers that we need several new states in the state machine just for this terminal. We're unlikely to do this, especially when OSC/DCS/etc. already exist for this precise purpose, and this is indeed how xterm does it.

2) The sequence is (sometimes) terminated by a control character in the C0 set. Control characters are normally processed separately from the rest of the state machine. Also, NUL specifically is discarded as per VT100 spec.

Right now between these two things the sequences will leave artifacts on the screen for any terminal not modified to fully support them. Switch to OSC like xterm and you will immediately get a clean display from any decent terminal,

"only built on EFL and libc"

[Anonymous Coward]

Which means that it requires "only", well, uhm, these packages:

atk-2.0.1, bitstream-vera-1.10_5, c-ares-config-1.9.1, ca_root_nss-3.14.1, cairo-1.10.2_5,2, compositeproto-0.4.2, curl-7.24.0_2, damageproto-1.2.1, dbus-1.4.14_4, dri2proto-2.6, e_dbus-1.7.5,1, ecore-con-1.7.5, ecore-evas-1.7.5, ecore-file-1.7.5, ecore-imf-1.7.5, ecore-imf_evas-1.7.5, ecore-input-1.7.5, ecore-input_evas-1.7.5, ecore-main-1.7.5_1, ecore-x11-1.7.5, edje-1.7.5,2, eet-1.7.5,2, efreet-1.7.5, eina-1.7.5, eio-1.7.5, elementary-1.7.5, embryo-1.7.5,2, emotion-1.7.5,1, encodings-1.0.4,1, ethumb-1.7.5, evas-core-1.7.5_1, evas-engine-buffer-1.7.5, evas-engine-opengl-1.7.5, evas-engine-x11-1.7.5, evas-loader-eet-1.7.5, evas-loader-jpeg-1.7.5, evas-loader-png-1.7.5, expat-2.0.1_2, fixesproto-5.0, font-bh-ttf-1.0.3, font-misc-ethiopic-1.0.3, font-misc-meltho-1.0.3, font-util-1.2.0, fontconfig-2.9.0,1, freetype2-2.4.11, fribidi-0.19.2_1, gamin-0.1.10_4, gdk-pixbuf-2.23.5_3, gettext-0.18.1.1, gio-fam-backend-2.28.8_1, glib-2.28.8_5, gnome_subr-1.0, gobject-introspection-0.10.8_3, gstreamer-0.10.36, gstreamer-ffmpeg-0.10.13, gstreamer-plugins-0.10.36_2,3, gstreamer-plugins-good-0.10.31,3, gtk-update-icon-cache-2.24.6_1, hicolor-icon-theme-0.12, inputproto-2.0.2, jasper-1.900.1_10, jbigkit-1.6, jpeg-8_4, kbproto-1.0.5, libGL-7.6.1_2, libGLU-7.6.1_1, libICE-1.0.7,1, libSM-1.2.0,1, libX11-1.4.4,1, libXScrnSaver-1.2.1, libXau-1.0.6, libXcomposite-0.4.3,1, libXcursor-1.1.12, libXdamage-1.1.3, libXdmcp-1.1.0, libXext-1.3.0_1,1, libXfixes-5.0, libXft-2.1.14, libXi-1.4.5,1, libXinerama-1.1.1,1, libXrandr-1.3.2, libXrender-0.9.6, libXt-1.1.1,1, libXv-1.0.6,1, libXxf86vm-1.1.1, libdrm-2.4.17_1, libexif-0.6.20, libffi-3.0.11, libfontenc-1.1.0, libiconv-1.14, libpciaccess-0.12.1, libpthread-stubs-0.3_3, libxcb-1.7, libxml2-2.7.8_5, lua-5.1.5_5, mkfontdir-1.0.6, mkfontscale-1.0.9, orc-0.4.16_1, pango-1.28.4_1, pciids-20130201, pcre-8.32, perl-5.14.2_2, pixman-0.24.2, pkgconf-0.8.9, png-1.5.14, python27-2.7.3_6, randrproto-1.3.2, renderproto-0.11.1, scrnsaverproto-1.2.1, shared-mime-info-1.0_2, tiff-4.0.3, videoproto-2.3.1, xcb-util-0.3.9_1,1, xcb-util-renderutil-0.3.8, xextproto-7.2.0, xf86vidmodeproto-2.3.1, xineramaproto-1.2.1, xorg-fonts-truetype-7.5.1, xproto-7.0.22

(Taken from freebsd ports, expect a similar list for other distributions, linux or otherwise.)

This shouldn't be surprising when libc itself has become a byword for bloat due to sheer size. Then again, this is software we're talking about, where the L in LDAP stands for "lightweight" and indeed it is, if you compare it to its even more bloated predecessor, at least for the first release. A common theme in software. But it really shouldn't be a contest, or if it is the goal ought to be the reverse: Do more with less code, resources, and so on. No, this does not mean "resurrect A/PL and write one-liners", thank you.

We have a long way to go yet and we're insisting on going the other way. Yeah, we'll get there, sure we will.

Re:"only built on EFL and libc"

[Anonymous Coward]

This shouldn't be surprising when libc itself has become a byword for bloat due to sheer size.

Lots of functions + integrating lost of stuff into one piece + modular X + modular E + modular Gtk == lots of dependencies.

The bloat is totally subjective metric. If you need a single application which does lots of things - it is inevitably bloated. But that is intended. Emacs and Eclipse are bloated - but very few users are complaining about it.

Re:"only built on EFL and libc"

[raster]

Me (author) doesn't care about this as these are already the requirements of e17 anyway, so for the target audience or doesn't need extra dependencies they don't already have. By the time you have any featured desktop installed you have at least this much installed.

Re:"only built on EFL and libc"

[realityimpaired]

You're clearly not already running e17 from that list of dependencies... your complaint is akin to somebody complaining that installing kopete on their gnome system pulls in a ton of unneeded deps.

From a system that's already running e17:

tara@MarchHare:~$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
tara@MarchHare:~$ sudo apt-get install terminology
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
    terminology
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 839 kB of archives.
After this operation, 3,118 kB of additional disk space will be used.
Get:1 http://packages.bodhilinux.com/bodhi/ precise/stable terminology amd64 20130326-1 [839 kB]
Fetched 839 kB in 1s (480 kB/s)
Selecting previously unselected package terminology.
(Reading database ... 279968 files and directories currently installed.)
Unpacking terminology (from .../terminology_20130326-1_amd64.deb) ...
Processing triggers for desktop-file-utils ...
Setting up terminology (20130326-1) ...

'nuf said?

Re:"only built on EFL and libc"

[Anonymous Coward]

Sometimes I think people will find anything they can to complain about. Of course you'll need libraries to render the pictures and play back video, not to mention all the other features. And since it is part of Enlightenment, why shouldn't it utilize the libraries that are already there? It's not like there aren't other tiny terminal emulators around. I haven't played with E17 in a while, but this makes me think I should at least look to see about installing this. I just wish there was some way to have something like this running over ssh through Putty (or another cross platform client), but sshfs is quite workable for that sort of stuff.

Re:"only built on EFL and libc"

[Crimey McBiggles]

No one's complaining about bloat in Emacs or Eclipse because users who care about bloat have all switched to other editors. Eclipse is an abomination.

Re:"only built on EFL and libc"

[Anonymous Coward]

Please ignore all the sour-faced whingers, most of them will just attack anything different as a reflex.

I think this is an interesting and useful contribution and I would use it like a shot if I used e17.

Terminals with graphical capabilities...

[phrank]

...have existed for a long time. For example the DEC dxterm supports escape sequences for drawing line, box, circle and oval primitives.
Nonetheless I am really impressed by this newfangled Enlightenment thingy. Image previews in file listings are useful. Also horizontal and vertical splitting.

Re:Terminals with graphical capabilities...

[Rude Turnip]

In the financial world, you also have the Bloomberg terminal. It's very heavily command line driven, although it does have some pointy-clicky functionality for noobs. You get a mix of text, graphics, audio and video from what I'd call a self-contained semantic web.

Re:Terminals with graphical capabilities...

[jabberw0k]

That's Digital's ReGIS command set, introduced in the 1980s. Even further back, the Tektronix 4010 terminal introduced vector commands circa 1972.

Turing Test Completed

[organgtool]

Who cares about image and video preview in a terminal? I'm more blown away by the fact that the terminal is self-aware!

a material improvement to terminals

[segfault_0]

Cmon, this is a real improvement to the functionality provided by modern linux terminals. I think it's cool as hell.

Re:a material improvement to terminals

[jago25_98]

I agree. It's exactly where the linux desktop improvements need to be - doing the desktop in the linux way rather than copying.

I'd like to see more drag and drop linking to programs; edit those pix, imagemagick those pics into a flow of processing and so on.

The copy and paste improvement is good. Seeing the pics is good. The eye candy... meh. Possibly that's what put a lot of people of reading the article and we only have a few comments. I admit I usually skip anything from Enlightenment.

I'll keep an eye out for a separate package but otherwise I guess I might install side by side with XFCE, use XFCE and this as terminal.

just linux

[xx_haze]

I can already launch anything from terminal, just with other apps just like > vlc "filename", if I'm in the directory this file is.. so why make terminal do things it supposed not to? Cause you can, and that's what makes Linux different from Windows where are locked in dead environment that updates every app randomly on start...

Re:just linux

[gagol]

I will certainly not use this new "terminal" but I can see how some people will appreciate it. Cool thing about linux, if you dont like this, use that or that or that or... instead. Godspeed to developers.

Win 9

[Anonymous Coward]

Windows 9 user-interface pre-alpha looks good.

Re:Learn the truth... apk

[UncleRage]

..and you can use Terminology to edit that Hosts file, too.

Who'd have thought this troll would have an actual reference point to a submission...

Why is this big news?

[Mister Liberty]

After all, playing video and displaying pdf's have been
solved problems for decades.

What does it matter what 'shell' program is built around
such functionality?

I am sympathetic towards Enlightenment, but this I don't
get. And by the way, doesn't this run in the face of the old
UNIX adagium 'modularity'?

Re:Why is this big news?

[raster]

it's modular. just at the library level which does make for a lot more efficiency. :) and what is new here - bringing the usability to your regular cmdline terminal without the need for launching other apps in windows... oh and did you read? it can render with opengl.. THAT is not exactly old hat.. AND it works in the framebuffer without x... and gives u moue control and copy and paste... IN the framebuffer... AND.. its like 20 TIMES faster than the kernel text console (try see how long u ait for a file to cat in the console vt)... and then in your console u can view pdf's, images and videos... the SAME as you do in x... oh and tabs and splits will work in the fb too... oh and it works in wayland too... not like there are a lot of terminals for wayland atm.

Re:Why is this big news?

[Samantha Wright]

If you want something to really get hopping mad about, terminals that can do this have been around for years. Ages, in fact.

Re:Why is this big news?

[svn]

If you want something to really get hopping mad about, terminals that can do this have been around for years. Ages, in fact.

Nice to know that xmlterm is still remembered (author). There is now an updated version, called GraphTerm, which is similar in some respects to Terminology but is written in python works completely within the browser.

Re:Learn the truth... apk

[Anonymous Coward]

Just report and move on, report and move on...

Way to go, E!

[yet-another-lobbyist]

I think this is goddamn just awesome. The only question I have is: why didn't someone think about this before?

I often find myself switching between CLI and GUI, either of which has usability advantages depending on the problem at hand. This one has a good chance of combining the some of advantages of both and come out as a solution outperforming either of the two traditional options. Nice job! So inspiring. Very creative! Way to go, E!

Re:Way to go, E!

[raster]

people did think about it before, but it has pretty much become forgotten, and hasn't been slickened up and polished and shipped in a modern terminal. it hasn't been demoed or shoved in peoples faces to get them to think "wait a sec.. if THAT is possible... what could i DO with it?". this is not an end. it's a beginning. it's trying to say "hey people. you don't HAVE to JUST do text. what if you wrote your shell scripts or other cmd line tools to assume such capabilities... what would YOU do with it? would you make an mc that has thumbnails and inlined image display? would you create a smart find/locate that displays thumbnails? would you add thumbnails to grep -r? what about a text irc client that used this and when someone posted imgur links it translated them into thumbnails right inline - no need to click. just see (ok could be nsfw sometimes).

my point being.. it's a START to make ideas roll. without the FEATURE, the ideas don't start rolling. so make the feature. show it works, fill in the missing blanks/gaps as people start to explore and push it, then add more. run with it. why should my terminal be stuck in a text ONLY world? why shouldn't modern datatypes (media for example) be part of it too, if i so desire?

The useful feature here

[Anonymous Coward]

... is the box select.